Searched the docs, but to no avail.
What is the maximum length for an enumeration value, i.e. the string literal?
The limit isn't on the length of the literal string, but rather on the table definition.
The MySQL documentation states that
Each table has an .frm file that contains the table definition. The server uses the following expression to check some of the table information stored in the file against upper limit of 64KB.
which is then followed by an ad-hoc equation expressing the approximate size of a table definition.
For a simple test, in a table with a couple fields already, I got my enum up to 63136 characters long, and the .frm was 71775 bytes big (slightly larger than 70KB), so the limit is approximate. At that point, MySQL complained #1117 - Too many columns, which is misleading to say the least.
Interestingly/oddly/worthwhile to note, the character set of the enum will change the maximum length. -- even if you're using normal characters which should only require 1 byte each.
An ENUM column can have a maximum of 65,535 distinct elements. (The practical limit is less than 3000.) A table can have no more than 255 unique element list definitions among its ENUM and SET columns considered as a group.
Related
I want to save some sequence of digits, which may be a number (eg 12345, 1230) or not (eg 00123, 0120). Which type of column is the most effective (by memory, by indexing speed) for that purpose?
Also, I need to store strings of characters from specially defined alphabet (eg "digits and comma" or "digits and english letters and dots and commas"). How to effectively do this?
Can I set limits on CHAR/VARCHAR type of a column to reduce the memory size it takes?
This is no different from any string column which implies varchar/text type.
VARCHAR(n) takes care of storage dynamically.
Reference here.
For constraining allowed symbols you could use CHECK constraints, but they don't work in MySQL so a workaround is to use trigger and define accepted characters there. See this question.
You could use REGEXP function to define your allowed alphabet.
For sql you can go with
varchar() and if your using POSTgreSQL you can make use of something
known as citext
If you have a MySQL table with a very large number of rows that includes a variable length field that is often used in WHERE or ORDER BY clauses, and it is infrequent that INSERTS or UPDATES are made, then it would be a good candidate for using an index on the field.
However, from what I could find on the topic, it seems MySQL doesn't handle variable length fields very quickly (compared to fixed length fields) when you index them in this manner. So, I was wondering if it would make sense to left pad the column's rows with empty strings to force all of them to some fixed maximum length. Would this make any sense at all? Or am I just over thinking this?
After consulting the manual some more, I realize this is a "feature" already baked into MySQL:
The length of a CHAR column is fixed to the length that you declare
when you create the table. The length can be any value from 0 to 255.
When CHAR values are stored, they are right- padded with spaces to the
specified length. When CHAR values are retrieved, trailing spaces are
removed.
Here is something that troubles me as I am creating a database table columns. For each of these there is a data type which has it's length. For e.g say one of the tables is a file path, and I assume this file path to be not longer than 100 in length at max, obviously i specify this as
filepath Varchar(100)
However, this still takes the same amount of memory space as say varchar(255) which is 1 byte. Given this, what is the benefit of me specifying the length as 100. Taking an outlier example, if my filepath exceeds varchar(100), does the database reject/trim down the filepath value to fit it to 100? Or does it allow it to exceed beyond 100 since the allotted memory space is still around 1 byte?
Essentially the above explanation frames my question as should one try and be very specific about the expected maximum length for a table column? Or just play it safe and specify the upper limit of the expected length of the table column depending on the memory requirement ?
Thanks much !
Parijat
MySQL will auto-truncate the value down to 100 characters. The number in the brackets for text/char fields is the MAXIMUM length. Note that this is a CHARACTER limit. If you've got a multibyte collation on that field, you can store more than 100 bytes in the field, but only 100 characters worth of text.
This is different than saying int(10), where the bracketed number is for display purposes only. An int is an int internally and takes up 16bits, regardless of how many digits you allow with the (#), but you'll never SEE more than those # digits.
very specific about the expected maximum length for a table column? Or just play it safe
If one would make a table containing addresses, you undoubtedly know that there will be some kind of limit to the length of the address. It would be useless to allow longer fields in the database.
You should play it safe, and be very careful.
when creating tables(and columns inside it) using MySQL gui clients there is a field called 'length' of a column. What exactly does it mean. Isn't range for a datatype (say)int fixed. Does length relate to the range of column value in anyway? Thanks.
Isn't range for a datatype (say)int fixed.
No - but MySQL has some predefined sizes for integers.
Does length relate to the range of column value in anyway
Yes, it sets a limit on the size of what you put in there - but don't assume its directly equivalent to the number of characters you key in (see previous link, also, this one on multibyte characters)
yes, indeed. E.g. a varchar(255) field can hold up to 255 characters.
see http://dev.mysql.com/doc/refman/5.0/en/data-types.html for all datatypes
How does MySQL store a varchar field? Can I assume that the following pattern represents sensible storage sizes :
1,2,4,8,16,32,64,128,255 (max)
A clarification via example. Lets say I have a varchar field of 20 characters. Does MySQL when creating this field, basically reserve space for 32 bytes(not sure if they are bytes or not) but only allow 20 to be entered?
I guess I am worried about optimising disk space for a massive table.
To answer the question, on disk MySql uses 1 + the size that is used in the field to store the data (so if the column was declared varchar(45), and the field was "FooBar" it would use 7 bytes on disk, unless of course you where using a multibyte character set, where it would be using 14 bytes). So, however you declare your columns, it wont make a difference on the storage end (you stated you are worried about disk optimization for a massive table). However, it does make a difference in queries, as VARCHAR's are converted to CHAR's when MySql makes a temporary table (SORT, ORDER, etc) and the more records you can fit into a single page, the less memory and faster your table scans will be.
MySQL stores a varchar field as a variable length record, with either a one-byte or a two-byte prefix to indicate the record size.
Having a pattern of storage sizes doesn't really make any difference to how MySQL will function when dealing with variable length record storage. The length specified in a varchar(x) declaration will simply determine the maximum length of the data that can be stored. Basically, a varchar(16) is no different disk-wise than a varchar(128).
This manual page has a more detailed explanation.
Edit: With regards to your updated question, the answer is still the same. A varchar field will only use up as much space on disk as the data you store in it (plus a one or two byte overhead). So it doesn't matter if you have a varchar(16) or a varchar(128), if you store a 10-character string in it, you're only going to use 10 bytes (plus 1 or 2) of disk space.