MySql Binary query











up vote
1
down vote

favorite












I have a table with a Binary PK:



CREATE TABLE `codes` (
`Code` binary(45) NOT NULL,

PRIMARY KEY (`Code`),
UNIQUE KEY `Code_UNIQUE` (`Code`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;


When I insert I use BINARY('value').



I attempted to retrieve a row by Code using the following:



SELECT * from codes WHERE `Code` = BINARY('value')


This doesn't work because the length of the Code field is 45, so MySql pads the data with empty bytes.



This can be visualised running the following:



SELECT HEX(Code), HEX(BINARY('value')) FROM codes 


enter image description here



I can get it to work with this (ugly) query:



SELECT * FROM codes WHERE TRIM('0' from HEX(Code)) = HEX(BINARY('value'))


So I was just wondering if anyone can provide a nice and performant way to achieve this. This is straightforward if you know the size of your data, but the Code field can be any length.










share|improve this question
























  • Can you provide some sample data showcasing this. A DB / SQL fiddle would be handy.
    – Madhur Bhaiya
    Nov 11 at 6:00










  • @Madhur Bhaiya Updated with a screenshot
    – joepour
    Nov 11 at 6:15










  • Images never help! Because we cannot reproduce the case. You can either provide us with the DDL statements for your table(s); or it would be even better if you can directly provide a db-fiddle.com
    – Madhur Bhaiya
    Nov 11 at 6:24










  • @MadhurBhaiya db-fiddle.com/f/3eqCCdEQPsiuxhjef2xHtb/0
    – joepour
    Nov 11 at 6:41















up vote
1
down vote

favorite












I have a table with a Binary PK:



CREATE TABLE `codes` (
`Code` binary(45) NOT NULL,

PRIMARY KEY (`Code`),
UNIQUE KEY `Code_UNIQUE` (`Code`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;


When I insert I use BINARY('value').



I attempted to retrieve a row by Code using the following:



SELECT * from codes WHERE `Code` = BINARY('value')


This doesn't work because the length of the Code field is 45, so MySql pads the data with empty bytes.



This can be visualised running the following:



SELECT HEX(Code), HEX(BINARY('value')) FROM codes 


enter image description here



I can get it to work with this (ugly) query:



SELECT * FROM codes WHERE TRIM('0' from HEX(Code)) = HEX(BINARY('value'))


So I was just wondering if anyone can provide a nice and performant way to achieve this. This is straightforward if you know the size of your data, but the Code field can be any length.










share|improve this question
























  • Can you provide some sample data showcasing this. A DB / SQL fiddle would be handy.
    – Madhur Bhaiya
    Nov 11 at 6:00










  • @Madhur Bhaiya Updated with a screenshot
    – joepour
    Nov 11 at 6:15










  • Images never help! Because we cannot reproduce the case. You can either provide us with the DDL statements for your table(s); or it would be even better if you can directly provide a db-fiddle.com
    – Madhur Bhaiya
    Nov 11 at 6:24










  • @MadhurBhaiya db-fiddle.com/f/3eqCCdEQPsiuxhjef2xHtb/0
    – joepour
    Nov 11 at 6:41













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have a table with a Binary PK:



CREATE TABLE `codes` (
`Code` binary(45) NOT NULL,

PRIMARY KEY (`Code`),
UNIQUE KEY `Code_UNIQUE` (`Code`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;


When I insert I use BINARY('value').



I attempted to retrieve a row by Code using the following:



SELECT * from codes WHERE `Code` = BINARY('value')


This doesn't work because the length of the Code field is 45, so MySql pads the data with empty bytes.



This can be visualised running the following:



SELECT HEX(Code), HEX(BINARY('value')) FROM codes 


enter image description here



I can get it to work with this (ugly) query:



SELECT * FROM codes WHERE TRIM('0' from HEX(Code)) = HEX(BINARY('value'))


So I was just wondering if anyone can provide a nice and performant way to achieve this. This is straightforward if you know the size of your data, but the Code field can be any length.










share|improve this question















I have a table with a Binary PK:



CREATE TABLE `codes` (
`Code` binary(45) NOT NULL,

PRIMARY KEY (`Code`),
UNIQUE KEY `Code_UNIQUE` (`Code`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;


When I insert I use BINARY('value').



I attempted to retrieve a row by Code using the following:



SELECT * from codes WHERE `Code` = BINARY('value')


This doesn't work because the length of the Code field is 45, so MySql pads the data with empty bytes.



This can be visualised running the following:



SELECT HEX(Code), HEX(BINARY('value')) FROM codes 


enter image description here



I can get it to work with this (ugly) query:



SELECT * FROM codes WHERE TRIM('0' from HEX(Code)) = HEX(BINARY('value'))


So I was just wondering if anyone can provide a nice and performant way to achieve this. This is straightforward if you know the size of your data, but the Code field can be any length.







mysql sql binary






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 11 at 6:14

























asked Nov 11 at 5:17









joepour

2,45682227




2,45682227












  • Can you provide some sample data showcasing this. A DB / SQL fiddle would be handy.
    – Madhur Bhaiya
    Nov 11 at 6:00










  • @Madhur Bhaiya Updated with a screenshot
    – joepour
    Nov 11 at 6:15










  • Images never help! Because we cannot reproduce the case. You can either provide us with the DDL statements for your table(s); or it would be even better if you can directly provide a db-fiddle.com
    – Madhur Bhaiya
    Nov 11 at 6:24










  • @MadhurBhaiya db-fiddle.com/f/3eqCCdEQPsiuxhjef2xHtb/0
    – joepour
    Nov 11 at 6:41


















  • Can you provide some sample data showcasing this. A DB / SQL fiddle would be handy.
    – Madhur Bhaiya
    Nov 11 at 6:00










  • @Madhur Bhaiya Updated with a screenshot
    – joepour
    Nov 11 at 6:15










  • Images never help! Because we cannot reproduce the case. You can either provide us with the DDL statements for your table(s); or it would be even better if you can directly provide a db-fiddle.com
    – Madhur Bhaiya
    Nov 11 at 6:24










  • @MadhurBhaiya db-fiddle.com/f/3eqCCdEQPsiuxhjef2xHtb/0
    – joepour
    Nov 11 at 6:41
















Can you provide some sample data showcasing this. A DB / SQL fiddle would be handy.
– Madhur Bhaiya
Nov 11 at 6:00




Can you provide some sample data showcasing this. A DB / SQL fiddle would be handy.
– Madhur Bhaiya
Nov 11 at 6:00












@Madhur Bhaiya Updated with a screenshot
– joepour
Nov 11 at 6:15




@Madhur Bhaiya Updated with a screenshot
– joepour
Nov 11 at 6:15












Images never help! Because we cannot reproduce the case. You can either provide us with the DDL statements for your table(s); or it would be even better if you can directly provide a db-fiddle.com
– Madhur Bhaiya
Nov 11 at 6:24




Images never help! Because we cannot reproduce the case. You can either provide us with the DDL statements for your table(s); or it would be even better if you can directly provide a db-fiddle.com
– Madhur Bhaiya
Nov 11 at 6:24












@MadhurBhaiya db-fiddle.com/f/3eqCCdEQPsiuxhjef2xHtb/0
– joepour
Nov 11 at 6:41




@MadhurBhaiya db-fiddle.com/f/3eqCCdEQPsiuxhjef2xHtb/0
– joepour
Nov 11 at 6:41












1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










Instead of Binary datatype, you should use Varbinary. This will not pad the data with trailing 0s, in case the length of data is smaller than the maximum size defined.




When BINARY values are stored, they are right-padded with the pad
value to the specified length. The pad value is 0x00 (the zero byte).
Values are right-padded with 0x00 on insert, and no trailing bytes are
removed on select.



For VARBINARY, there is no padding on insert and no bytes are stripped
on select.




Also, you do not need to define Unique constraint on an already defined Primary Key. Primary Key basically satisfied the Unique constraint, with additional condition of NOT NULL values. So, defining Unique constraint further does not add anything upon it.



This is how the CREATE TABLE statement can be:



CREATE TABLE `codes` (
`Code` Varbinary(45) NOT NULL, -- Changed to Varbinary

PRIMARY KEY (`Code`) -- Removed Unique constraint

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into codes (Code) VALUES (BINARY('value'));




Query #1



SELECT HEX(Code), HEX(BINARY('value')) FROM codes ;

| HEX(Code) | HEX(BINARY('value')) |
| ---------- | -------------------- |
| 76616C7565 | 76616C7565 |




Query #2



SELECT * from codes WHERE `Code` = BINARY('value');

| Code |
| --------------- |
| [object Object] |




View on DB Fiddle






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53246046%2fmysql-binary-query%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    2
    down vote



    accepted










    Instead of Binary datatype, you should use Varbinary. This will not pad the data with trailing 0s, in case the length of data is smaller than the maximum size defined.




    When BINARY values are stored, they are right-padded with the pad
    value to the specified length. The pad value is 0x00 (the zero byte).
    Values are right-padded with 0x00 on insert, and no trailing bytes are
    removed on select.



    For VARBINARY, there is no padding on insert and no bytes are stripped
    on select.




    Also, you do not need to define Unique constraint on an already defined Primary Key. Primary Key basically satisfied the Unique constraint, with additional condition of NOT NULL values. So, defining Unique constraint further does not add anything upon it.



    This is how the CREATE TABLE statement can be:



    CREATE TABLE `codes` (
    `Code` Varbinary(45) NOT NULL, -- Changed to Varbinary

    PRIMARY KEY (`Code`) -- Removed Unique constraint

    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

    insert into codes (Code) VALUES (BINARY('value'));




    Query #1



    SELECT HEX(Code), HEX(BINARY('value')) FROM codes ;

    | HEX(Code) | HEX(BINARY('value')) |
    | ---------- | -------------------- |
    | 76616C7565 | 76616C7565 |




    Query #2



    SELECT * from codes WHERE `Code` = BINARY('value');

    | Code |
    | --------------- |
    | [object Object] |




    View on DB Fiddle






    share|improve this answer



























      up vote
      2
      down vote



      accepted










      Instead of Binary datatype, you should use Varbinary. This will not pad the data with trailing 0s, in case the length of data is smaller than the maximum size defined.




      When BINARY values are stored, they are right-padded with the pad
      value to the specified length. The pad value is 0x00 (the zero byte).
      Values are right-padded with 0x00 on insert, and no trailing bytes are
      removed on select.



      For VARBINARY, there is no padding on insert and no bytes are stripped
      on select.




      Also, you do not need to define Unique constraint on an already defined Primary Key. Primary Key basically satisfied the Unique constraint, with additional condition of NOT NULL values. So, defining Unique constraint further does not add anything upon it.



      This is how the CREATE TABLE statement can be:



      CREATE TABLE `codes` (
      `Code` Varbinary(45) NOT NULL, -- Changed to Varbinary

      PRIMARY KEY (`Code`) -- Removed Unique constraint

      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

      insert into codes (Code) VALUES (BINARY('value'));




      Query #1



      SELECT HEX(Code), HEX(BINARY('value')) FROM codes ;

      | HEX(Code) | HEX(BINARY('value')) |
      | ---------- | -------------------- |
      | 76616C7565 | 76616C7565 |




      Query #2



      SELECT * from codes WHERE `Code` = BINARY('value');

      | Code |
      | --------------- |
      | [object Object] |




      View on DB Fiddle






      share|improve this answer

























        up vote
        2
        down vote



        accepted







        up vote
        2
        down vote



        accepted






        Instead of Binary datatype, you should use Varbinary. This will not pad the data with trailing 0s, in case the length of data is smaller than the maximum size defined.




        When BINARY values are stored, they are right-padded with the pad
        value to the specified length. The pad value is 0x00 (the zero byte).
        Values are right-padded with 0x00 on insert, and no trailing bytes are
        removed on select.



        For VARBINARY, there is no padding on insert and no bytes are stripped
        on select.




        Also, you do not need to define Unique constraint on an already defined Primary Key. Primary Key basically satisfied the Unique constraint, with additional condition of NOT NULL values. So, defining Unique constraint further does not add anything upon it.



        This is how the CREATE TABLE statement can be:



        CREATE TABLE `codes` (
        `Code` Varbinary(45) NOT NULL, -- Changed to Varbinary

        PRIMARY KEY (`Code`) -- Removed Unique constraint

        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

        insert into codes (Code) VALUES (BINARY('value'));




        Query #1



        SELECT HEX(Code), HEX(BINARY('value')) FROM codes ;

        | HEX(Code) | HEX(BINARY('value')) |
        | ---------- | -------------------- |
        | 76616C7565 | 76616C7565 |




        Query #2



        SELECT * from codes WHERE `Code` = BINARY('value');

        | Code |
        | --------------- |
        | [object Object] |




        View on DB Fiddle






        share|improve this answer














        Instead of Binary datatype, you should use Varbinary. This will not pad the data with trailing 0s, in case the length of data is smaller than the maximum size defined.




        When BINARY values are stored, they are right-padded with the pad
        value to the specified length. The pad value is 0x00 (the zero byte).
        Values are right-padded with 0x00 on insert, and no trailing bytes are
        removed on select.



        For VARBINARY, there is no padding on insert and no bytes are stripped
        on select.




        Also, you do not need to define Unique constraint on an already defined Primary Key. Primary Key basically satisfied the Unique constraint, with additional condition of NOT NULL values. So, defining Unique constraint further does not add anything upon it.



        This is how the CREATE TABLE statement can be:



        CREATE TABLE `codes` (
        `Code` Varbinary(45) NOT NULL, -- Changed to Varbinary

        PRIMARY KEY (`Code`) -- Removed Unique constraint

        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

        insert into codes (Code) VALUES (BINARY('value'));




        Query #1



        SELECT HEX(Code), HEX(BINARY('value')) FROM codes ;

        | HEX(Code) | HEX(BINARY('value')) |
        | ---------- | -------------------- |
        | 76616C7565 | 76616C7565 |




        Query #2



        SELECT * from codes WHERE `Code` = BINARY('value');

        | Code |
        | --------------- |
        | [object Object] |




        View on DB Fiddle







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 11 at 9:25

























        answered Nov 11 at 9:17









        Madhur Bhaiya

        17.9k62236




        17.9k62236






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53246046%2fmysql-binary-query%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Bressuire

            Vorschmack

            Quarantine