Length of varchar column - is there an advantage to using 255?












1















I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage advantage to these kinds of lengths? Or is this old wisdom no longer applicable to current versions of MariaDB and MySQL?










share|improve this question


















  • 1





    Do you need 255 characters?

    – McNets
    4 hours ago











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    3 hours ago











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    3 hours ago











  • Simply use the length you need.

    – McNets
    2 hours ago











  • Possible duplicate of MySQL - varchar length and performance

    – Evan Carroll
    42 mins ago
















1















I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage advantage to these kinds of lengths? Or is this old wisdom no longer applicable to current versions of MariaDB and MySQL?










share|improve this question


















  • 1





    Do you need 255 characters?

    – McNets
    4 hours ago











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    3 hours ago











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    3 hours ago











  • Simply use the length you need.

    – McNets
    2 hours ago











  • Possible duplicate of MySQL - varchar length and performance

    – Evan Carroll
    42 mins ago














1












1








1








I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage advantage to these kinds of lengths? Or is this old wisdom no longer applicable to current versions of MariaDB and MySQL?










share|improve this question














I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage advantage to these kinds of lengths? Or is this old wisdom no longer applicable to current versions of MariaDB and MySQL?







mysql mariadb






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 4 hours ago









dbdemondbdemon

2,8722523




2,8722523








  • 1





    Do you need 255 characters?

    – McNets
    4 hours ago











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    3 hours ago











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    3 hours ago











  • Simply use the length you need.

    – McNets
    2 hours ago











  • Possible duplicate of MySQL - varchar length and performance

    – Evan Carroll
    42 mins ago














  • 1





    Do you need 255 characters?

    – McNets
    4 hours ago











  • Historical reasons, at least according to stackoverflow.com/questions/1217466/…

    – Jonathan Fite
    3 hours ago











  • @McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

    – dbdemon
    3 hours ago











  • Simply use the length you need.

    – McNets
    2 hours ago











  • Possible duplicate of MySQL - varchar length and performance

    – Evan Carroll
    42 mins ago








1




1





Do you need 255 characters?

– McNets
4 hours ago





Do you need 255 characters?

– McNets
4 hours ago













Historical reasons, at least according to stackoverflow.com/questions/1217466/…

– Jonathan Fite
3 hours ago





Historical reasons, at least according to stackoverflow.com/questions/1217466/…

– Jonathan Fite
3 hours ago













@McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

– dbdemon
3 hours ago





@McNets I actually need more than 255, but since that number is used so often, I thought I should use that as an example.

– dbdemon
3 hours ago













Simply use the length you need.

– McNets
2 hours ago





Simply use the length you need.

– McNets
2 hours ago













Possible duplicate of MySQL - varchar length and performance

– Evan Carroll
42 mins ago





Possible duplicate of MySQL - varchar length and performance

– Evan Carroll
42 mins ago










2 Answers
2






active

oldest

votes


















3














I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



Use a length that is




  • Big enough to conservatively never be exceeded, yet

  • As small as seems reasonable.


While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



Potential negative impacts of blindly using '255':




  • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

  • You could overflow a limit on index size.

  • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






share|improve this answer

































    1














    "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



    If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



    Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "182"
      };
      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',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      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%2fdba.stackexchange.com%2fquestions%2f227088%2flength-of-varchar-column-is-there-an-advantage-to-using-255%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      3














      I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



      In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



      A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



      Use a length that is




      • Big enough to conservatively never be exceeded, yet

      • As small as seems reasonable.


      While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



      Potential negative impacts of blindly using '255':




      • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

      • You could overflow a limit on index size.

      • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


      Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






      share|improve this answer






























        3














        I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



        In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



        A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



        Use a length that is




        • Big enough to conservatively never be exceeded, yet

        • As small as seems reasonable.


        While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



        Potential negative impacts of blindly using '255':




        • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

        • You could overflow a limit on index size.

        • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


        Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






        share|improve this answer




























          3












          3








          3







          I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



          In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



          A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



          Use a length that is




          • Big enough to conservatively never be exceeded, yet

          • As small as seems reasonable.


          While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



          Potential negative impacts of blindly using '255':




          • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

          • You could overflow a limit on index size.

          • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


          Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.






          share|improve this answer















          I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.



          In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on CHARACTER SET, etc.



          A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.



          Use a length that is




          • Big enough to conservatively never be exceeded, yet

          • As small as seems reasonable.


          While I am ranting... CHAR (fixed length) is rarely advised. And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)



          Potential negative impacts of blindly using '255':




          • If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.

          • You could overflow a limit on index size.

          • Complex SELECTs may need a temp table, and may use MEMORY for it. In this case, VARCHAR(255) becomes CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)


          Related: Don't blindly use BIGINT for all numbers. It takes 8 bytes. Even INT is overkill, at 4 bytes. See MEDIUMINT, SMALLINT, and TINYINT. Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 47 mins ago

























          answered 55 mins ago









          Rick JamesRick James

          41.3k22258




          41.3k22258

























              1














              "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



              If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



              Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






              share|improve this answer




























                1














                "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



                If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



                Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






                share|improve this answer


























                  1












                  1








                  1







                  "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



                  If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



                  Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.






                  share|improve this answer













                  "Standard" column lengths are used all over the place, and invariably indicate there was no effort performed to understand the actual required length of the column.



                  If you have a column where there will never be more than 24 characters used, why specify the length of the column as 255?



                  Analyzing and using the correct length for variable-length columns takes a small amount of effort, and ensures side effects of using too large a column length never become a problem. I know your question is about MySQL, however this answer shows how SQL Server uses column lengths in various ways that may not be apparent at first.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 55 mins ago









                  Max VernonMax Vernon

                  49.9k13111220




                  49.9k13111220






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Database Administrators Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f227088%2flength-of-varchar-column-is-there-an-advantage-to-using-255%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

                      What other Star Trek series did the main TNG cast show up in?

                      Berlina muro

                      Berlina aerponto