Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To answer your question: yes it'll get less performant. Obviously, the bigger the type, the bigger the table, the slower the queries (more I/O, bigger indexes, longer access time, result less likely to fit in the various caches, and so on). So as a rule of thumb: always use the <strong>smallest type</strong> that fits you need.</p> <p>That being said, <strong>performance doesn't matter</strong>. Why? Because when you reach a point where you overflow an INT, then BIGINT is the only solution and you'll have to live with it. Also at that point (considering you're using an auto increment PK, you'll be over 4 <strong>billions</strong> rows), you'll have bigger performance issues, and the overhead of a BIGINT compared to a INT will be the least of your concerns.</p> <p>So, consider the following points:</p> <ul> <li>Use UNSIGNED if you don't need negative values, that'll double the limit.</li> <li>UNSIGNED INT max value is 4.294.967.295. If you're using an auto increment PK, and <strong>you only have 300.000 entries, you really don't need to worry</strong>. You could even use a MEDIUMINT at the moment, unless you're planning for really really fast growth. (see <a href="http://dev.mysql.com/doc/refman/5.1/en/integer-types.html" rel="noreferrer">http://dev.mysql.com/doc/refman/5.1/en/integer-types.html</a>)</li> <li>The number in parenthesis after the type <strong>doesn't impact the max value of the type</strong>. INT(7) is the same as INT(8) or INT(32). It's used to indicate the display width if you specify ZEROFILL (see <a href="http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html" rel="noreferrer">http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html</a>)</li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POBIGINT mysql performance compared to INT
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USrubo77
    1. USrlanvin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POBIGINT mysql performance compared to INT
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis says everything I was about to. You have practically no chance of hitting the limit on an INT field unless you're dealing with a LOT of data (which 300,000 entries is NOT). Also as mentioned here the (7) doesn't really do anything to limit what the field stores. You've still got a limit of 4.3 billion (assuming you make it UNSIGNED)
      singulars
      1. PO
      1. USSimon at mso.net
    2. COi know about the sizes of int(7) and so on. but i dont use auto-increment in that table, cause the numbers are imported from another database, and they are much longer than 2 characters
      singulars
      1. PO
      1. USrubo77
    3. COThe fact that it's imported doesn't prevent you from using AUTO_INCREMENT - the AI value is automatically set the max value of the PK after a series of insert (and if not you can use ALTER to change it). Now if you do need BIGINT because you can have numbers over 10 digits long (this happens with serial numbers for example), then yes, it'll be slightly less efficient. If you're really really worried and have a huge trafic, you could use a separate (small) auto increment PK and store your BIGINT as a UNIQUE INDEX (but frankly I don't think it's worth the troubles)
      singulars
      1. PO
      1. USrlanvin
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload