我最初将我的字段设置为latin1_swedish_ci
,我将其更改为utf8_general_ci
(字段和表),然后发现我的查询从 ~1.8 秒变为 ~3.3。我在该字段上有一个索引,甚至重新创建了索引(删除然后添加)。该字段在 order by 子句中使用。
如果有问题或者这是否正常,有什么想法吗?
我正在运行 MySQL 5.0。
我最初将我的字段设置为latin1_swedish_ci
,我将其更改为utf8_general_ci
(字段和表),然后发现我的查询从 ~1.8 秒变为 ~3.3。我在该字段上有一个索引,甚至重新创建了索引(删除然后添加)。该字段在 order by 子句中使用。
如果有问题或者这是否正常,有什么想法吗?
我正在运行 MySQL 5.0。
latin1_swedish_ci
是每个字符一个八位字节的编码系统。一旦您知道比较字符和整个字符串的整理(或排序)顺序就相对简单了。
utf8_general_ci
每个字符需要一到四个八位字节。以这种编码方式解码八位字节数据更难,因此需要更长的时间。
我自己不经常使用 mysql,但我可能能够对问题所在提供一些见解。
latin1_swedish_ci 字符集是一个单字节编码系统,这意味着使用该系统编码的每个字符都只占用一个字节。将此与 utf8_general_ci 字符集进行对比,其中每个字符由每个字符一到四个八位字节组成,这意味着需要一到四个字节来表示每个字符。
这有一个明显的缺点,即 utf8 字符占用更多的空间、更多的内存,最重要的是,需要更多的 cpu 时间来识别。而最明显的优势是 utf8 字符可以编码为任何 unicode 字符。
由于这个问题标有“查询优化”,您需要问自己是否真的需要表示更“异国情调”的字符,或者单八位字节系统(例如纯 ASCII 表)中表示的字符是否是足以满足您的需求。因为从本质上讲,utf8 会吃掉更多的 CPU/内存。
您的查询看起来如何?
您是否可以在该字段上使用过滤器,并将参数的数据类型指定为非 utf8 数据类型?在这种情况下,DBMS 将不得不进行一些强制转换,这会影响性能。