I used to use a query in mySQL that tells me how big my query is.
However, I don't remember that query and can't seem to find it now.
Does anyone know that syntax on top of their head?
Basically it allows me to know how much in size I saved from using a 11 bit integer vs 2 bit integer etc.
Thanks,
Tee
Here's an overview, also with all data types: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html
You can use SHOW TABLE STATUS LIKE 'MY_TABLE' to return a bunch of information about the table. The Data_length column will contain the size of the data file used for that table. There is also an "average row length", Avg_row_length, that might be useful.
See here for details: http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html.
As mentioned in my comment above though, the number after an int declaration, int(11), does not affect the size of the data structure that holds the integer. It only affects the display width of the column. Furthermore, you will only see its effect if you are using ZEROFILL.
Related
I'm trying to understand why this is happening but I couldn't find anything in the internet.
I have a table of meds(called Medicamento) which has 23600 elements in it.
When I try to take an element using the IdMed column it only takes the values with less than 6 digits. Example 1:
SELECT * FROM `Medicamento` WHERE IdMed=100
Example 2:
SELECT * FROM `Medicamento` WHERE IdMed=200703
At this point I thought that the med with that Id was not created so I did this last query which made me not knowing where the mistake is:
SELECT * FROM `Medicamento` WHERE IdMed>200702
Result:
As you can see the first element is the one with the 200703 Id. What I cannot understand is why it takes elemnts with Id's such as 12700 or 100 but it doesn't take elements with Id's of 6 numbers. I thought it could be a matter of formats but I didn't find anything helpful.
Data of the table was taken from 2 different .xlsx files, that's why I thought about formats.
PD: Sorry for my bad English. I hope the problem is understood.
EDIT:
Table data types
In a nutshell, what's happening is your value is losing precision because you're using an inaccurate data type. float is for floating point numbers, and ideally shouldn't normally be used as a primary key. your best bet is to change this to an integer data type instead. By the looks of the comments, this may not be viable, you're probably best off to create another column and use THAT as the primary key instead. What's likely happening is for example with 200703, it's potentially being stored in the database as 200703.000001 or 2007002.99999 and you're searching for a value that's not an exact match to how the database is storing it.
As a suggestion, you may want to change your current float column to a double column instead to retain a little more precision beyond the decimal point.
I need to create a database that stores the following content (about 5,765 entries total): http://s18.postimg.org/s73exwemf/Capture.jpg
I'm using MySQL Workbench to create my schema. So far I have one table with the following columns:
EPSG Code (INT) - PK, NN
CRS_NAME CHAR(50) - UQ
CRS_TYPE - ENUM('Projected', 'Geographic 2D', 'Geographic 3D', 'Geocentric', 'Vertical', 'Compound')
PROJ_FILE - CHAR(800)
Do my dataypes make sense? Generally, I will retrieve the CRS Name, type and proj file contents using the EPSG code. But sometimes, the only information available may be the CRS name. That's why I made CRS_NAME a unique index.
Does that make sense? I'm new to SQL and I'm enjoying it so far.
The following is for the most part personal preferences developed over almost 10 years of working with databases (MySQL mostly).
CRS_NAME: Unique key sounds appropriate to me.
CRS_TYPE: I tend to stay away from enum in the database. Instead, I suggest a separate CRS_TYPE table, and putting a CRS_TYPE_ID field
in the table instead of an enum type. I would not make CRS_TYPE.ID an
auto-increment; ideally, you want it to reflect the values used in an
enum in whatever programming language you might work with.
(Technically, the additional table is only necessary for
documentation and easier reporting purposes.)
PROJ_FILE: TINYTEXT, MEDIUMTEXT, TEXT, etc... might be a better option (or equivalent BLOBs). CHAR(800) is going to use 800 (or more
depending on character set) bytes whether it holds nothing or is
full. VARCHAR(800) could be better (from a space used perspective), but if
using MyISAM engine, causes data rows to be dynamic (slowing
queries). Regardless of engine used, TEXT and BLOB types only take up
as much room as they need and don't "fragment" tables like VARCHAR.
The downside is they are little more complicated to search within
and index.
I have reached the limit set on the row size of a table, so I'm not able to add any more columns to the table.
I'm getting the following error:
.#1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to
TEXT or BLOBs
I have researched this issue on the MySQL website, but am still unsure about how to fix this problem.
Does anyone know how I can fix this issue, and what setting or script that I would need to run to modify the setting so it allows me to add more columns to the table?
Why is your row size 64k to begin with? That is your problem. Not the setting being too low.
From:
http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html
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 an upper limit of 64KB:
> if (info_length+(ulong) create_fields.elements*FCOMP+288+
> n_length+int_length+com_length > 65535L || int_count > 255)
So it's not likely something you can easily change (short of modifying source code and running a custom MySQL. Give us your schema and we might be able to better advise, but the short answer would seem to be that you have too many columns, or need to change some VARCHARs etc. to be text/blob.
Without seeing the (likely abomination of a) schema, it's hard to advise.
I've been inserting some numbers as INT UNSIGNED in MySQL database. I perform search on this column using "SELECT. tablename WHERE A LIKE 'B'. I'm coming across some number formats that are either too long for unsigned integer or have dashes in them like 123-456-789.
What are some good options for modifying the table here? I see two options (are there others?):
Make another column (VARCHAR(50)) to store numbers with dashes. When a search query detects numbers with dashes, look in this new column.
Recreate the table using a VARCHAR(50) instead of unsigned integer for this column in question.
I'm not sure which way is the better in terms of (a) database structure and (b) search speed. I'd love some inputs on this. Thank you.
Update: I guess I should have included more info.
These are order numbers. The numbers without dashes are for one store (A), and the one with dashes are for Amazon (B; 13 or 14 digits I think with two dashes). A's order numbers should be sortable. I'm not sure if B has to be since the numbers don't mean anything to me really (just a unique number).
If I remove the dashes and put them all together as big int, will there be any decrease in performance in the search queries?
the most important question is how you would like to use the data. What do you need? If you make a varchar, and then you would like to sort it as a number, you will not be able to, since it will be treating it as string..
you can always consider big int, however the question is: do you need dashes? or can you just ignore them on application level? if you need them, it means you need varchar. in that case it might make sense to have two columns if you want to be able to for example sort them as numbers, or perform any calculations. otherwise probably one makes more sense.
you should really provide more context about the problem
Mysql has the PROCEDURE ANALYSE , which helps you to identify with your existing data sets. here's some example.
Given you are running query WHERE A LIKE 'B' mainly. You can also try full text search if "A" varies a lot.
I think option 2 makes the most sense. Just add a new column as varchar(50), put everything in the int column into that varchar, and drop the int. Having 2 separate columns to maintain just isn't a good idea.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Are there disadvantages to using a generic varchar(255) for all text-based fields?
In MYSQL you can choose a length for the VARCHAR field type. Possible values are 1-255.
But what are its advantages if you use VARCHAR(255) that is the maximum instead of VARCHAR(20)? As far as I know, the size of the entries depends only on the real length of the inserted string.
size (bytes) = length+1
So if you have the word "Example" in a VARCHAR(255) field, it would have 8 bytes. If you have it in a VARCHAR(20) field, it would have 8 bytes, too. What is the difference?
I hope you can help me. Thanks in advance!
Check out: Reference for Varchar
In short there isn't much difference unless you go over the size of 255 in your VARCHAR which will require another byte for the length prefix.
The length indicates more of a constraint on the data stored in the column than anything else. This inherently constrains the MAXIMUM storage size for the column as well. IMHO, the length should make sense with respect to the data. If your storing a Social Security # it makes no sense to set the length to 128 even though it doesn't cost you anything in storage if all you actually store is an SSN.
There are many valid reasons for choosing a value smaller than the maximum that are not related to performance. Setting a size helps indicate the type of data you are storing and also can also act as a last-gasp form of validation.
For instance, if you are storing a UK postcode then you only need 8 characters. Setting this limit helps make clear the type of data you are storing. If you chose 255 characters it would just confuse matters.
I don't know about mySQL but in SQL Server it will let you define fields such that the total number of bytes used is greater than the total number of bytes that can actually be stored in a record. This is a bad thing. Sooner or later you will get a row where the limit is reached and you cannot insert the data.
It is far better to design your database structure to consider row size limits.
Additionally yes, you do not want people to put 200 characters in a field where the maximum value should be 10. If they do, it is almost always bad data.
You say, well I can limit that at the application level. But data does not get into the database just from one application. Sometimes multiple applications use it, sometimes data is imported and sometimes it is fixed manually from the query window (update all the records to add 10% to the price for instance). If any of these other sources of data don't know about the rules you put in your application, you will have bad, useless data in your database. Data integrity must be enforced at the database level (which doesn't stop you from also checking before you try to enter data) or you have no integrity. Plus it has been my experience that people who are too lazy to design their database are often also too lazy to actually put the limits into the application and there is no data integrity check at all.
They have a word for databases with no data integrity - useless.
There is a semantical difference (and I believe that's the only difference): if you try to fill 30 non-space characters into varchar(20), it will produce an error, whereas it will succeed for varchar(255). So it is primarily an additional constraint.
Well, if you want to allow for a larger entry, or limit the entry size perhaps.
For example, you may have first_name as a VARCHAR 20, but perhaps street_address as a VARCHAR 50 since 20 may not be enough space. At the same time, you may want to control how large that value can get.
In other words, you have set a ceiling of how large a particular value can be, in theory to prevent the table (and potentially the index/index entries) from getting too large.
You could just use CHAR which is a fixed width as well, but unlike VARCHAR which can be smaller, CHAR pads the values (although this makes for quicker SQL access.
From a database perspective performance wise I do not believe there is going to be a difference.
However, I think a lot of the decision on the length to use comes down to what you are trying to accomplish and documenting the system to accept just the data that it needs.