SQL SELECT speed int vs varchar
我正在创build一张桌子，这让我感到惊讶。
如果我存储，说汽车有制造（fx宝马，奥迪等），如果我作为一个int或varchar存储的make会对查询速度有所不同。
那么
SELECT * FROM table WHERE make = 5 AND ...; 比…更快/更慢
SELECT * FROM table WHERE make = 'audi' AND ...;
或者速度会差不多呢？
Int比较比varchar比较快，简单的事实是int比varchars占用更less的空间。
无索引和索引访问都适用。 最快的方法是索引int列。
正如我看到你已经标记了问题postgreql，你可能会对不同datetypes的空间使用感兴趣：
-
int字段占用2到8个字节 ，其中4个通常足够多（-2147483648到+2147483647） - 字符types占用4个字节加上实际的string 。
一些大致的基准：
Postgres 9.x中有4百万条logging
Table A = base table with some columns Table B = Table A + extra column id of type bigint with random numbers Table C = Table A + extra column id of type text with random 16-char ASCII strings
8GB内存，i7，SSD笔记本上的结果：
Size on disk: A=261MB B=292MB C=322MB Non-indexed by id: select count(*), select by id: 450ms same on all tables Insert* one row per TX: B=9ms/record C=9ms/record Bulk insert* in single TX: B=140usec/record C=180usec/record Indexed by id, select by id: B=about 200us C=about 200us * inserts to the table already containing 4M records
所以它看起来像这样的设置，只要你的索引适合内存，bigint与16字符文本没有速度上的差异。
使用int而不是varchar会更快一些。 速度更重要的是在查询可以用来查找logging的字段上有一个索引。
还有另一个使用int的原因，那就是规范化数据库。 不要在表格中存储“梅赛德斯 – 奔驰”文本数千次，而应将其存储为ID，并将品牌名称存储在单独的表格中。
分解string比较与非浮点数的实际性能，在这种情况下，任何大小的无符号和有符号都没有关系。 大小实际上是真正的性能差异。 不pipe是1字节+（高达126字节）还是1,2,4字节或8字节的比较…显然非浮点数都小于string和浮点数，因此在汇编时更友善。
所有语言中string与string比较的速度比CPU在1条指令中可以比较的要慢。 即使比较32位CPU上的8个字节（64位）仍然比VARCHAR（2）或更快。 *再次看看生成的程序集（甚至是手工），它需要更多的指令来比较字符比1到8字节的CPU数字。
现在，多快？ 也取决于数据量。 如果你只是比较5'奥迪' – 这是你所有的数据库，所造成的差异是如此之小，你永远不会看到它。 根据CPU，实现（客户机/服务器，网页/脚本等），你可能不会看到它，直到你在数据库服务器上进行了几百次比较（甚至可能是几千个比较之前，它是显而易见的）。
- 消除关于散列比较的不正确争议。 大多数哈希algorithm本身都很慢，所以你不会从CRC64和更小的东西中受益。 在过去的12年中，我为多县search引擎开发了searchalgorithm，为信用局开发了7年。 任何你可以保持在数字更快…例如电话号码，邮政编码，甚至货币* 1000（存储）货币股利1000（检索）比DECIMAL比快速比较。
OZZ
一般来说int会更快。 varchar越长越慢
索引与否，int是更快（varchar越长，得到的越慢）。
另一个原因：varchar字段上的索引将比int更大。 对于更大的表，这可能意味着数百兆字节（和数千页）。 这使得性能变得更糟，因为单独阅读索引需要很多磁盘读取。
提示：如果字段make的可能值永远不会 （或很less）改变，那么可以使用ENUM作为折衷。 它结合了良好的速度和良好的可读性。
如果您在任何一个字段上打开索引 ，速度会更快。 至于你的问题，我认为int比varchar更快。
有点相对。 是的，INTs会更快，但问题是，如果在你的情况是显而易见的。 VARCHAR只是一些小字或更长的文本？ 以及表中有多less行？ 如果只有几行，它很可能会完全缓冲在内存中（如果经常请求的话），在这种情况下，你不会注意到很多的区别。 那么当然还有索引，这在表格增长时变得更重要。 使用固态硬盘可能会更快，高清与优化的查询。 有用的磁盘控制器有时也会加快查询速度> 10倍。 这可能会为使用VARCHAR留出空间，这使得读写查询变得更容易（无需编写复杂的连接）并加快开发速度。 然而，纯粹主义者会不同意并且总是将所有事情正常化。
