MySQL性能：8.0和UTF8的影响

世界正在转向UTF8，MySQL 8.0现在默认使用utf8mb4字符集，但是，说实话，我很惊讶“charset”相关主题可能是多么明智...... - 实际上你可能很容易遇到巨大的性能开销通过使用围绕客户端/服务器charset和排序规则的“奇怪”配置设置。虽然为了避免客户端和服务器之间任何潜在的字符集不匹配，MySQL长期以来一直是一个很好的选择：“skip-character-set-client-handshake”，它强制任何客户端连接与服务器设置“对齐”！（有关详细信息，请参阅参考手册：https：//dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_character-set-client-handshake） - 默认情况下不设置此选项（让您自由选择在客户端和服务器端使用的字符集）。但是，在我看来，最好根据服务器设置调整客户端以避免任何潜在的客户端错误配置.. 

如果你想使用UTF8，请首先使用“utf8mb4”，它是最完整的任何类型字符（可能是今天唯一有意义的字符），第二个 - 相关代码在MySQL 8.0中得到了更多改进，以提高效率。效率更高？ - 让我们从以下测试结果中看出来。

但首先，相关的配置设置：

  的[mysqld]
   ...
   被character_set_server = utf8mb4 
   collat​​ion_server的= utf8mb4_0900_ai_ci
   跳过字符集客户端握手
   sort_buffer_size的值= 512K
  

注意：介意为UTF8使用更大的排序缓冲区

结果是在与之前发布的使用MySQL 8.0和latin1的RO测试相同的2S Skylake上获得的，并且具有相同的测试工作负载（仅适用于latin1，您需要更改character_set_server = latin1和collat​​ion_server = latin1_swedish_ci）

到目前为止，我们在这里：

Sysbench OLTP_RO 10Mx8-tables UTF8mb4 on 2S 48cores-HT Skylake

---

评论：

• MySQL 8.0的效果比5.7高出40％
• MariaDB 10.3.5正试图关注，但还没有...

Sysbench RO Point -在2S 48cores-HT Skylake上选择 10Mx8表UTF8mb4

---

评论：

• 点选工作量对UTF8来说不太合理
• 由于5.7中的RO修复，8.0和5.7的QPS最高
• 自采用InnoDB 5.7代码以来，MariaDB 10.3.5比以前更高
• 5.6比其他人慢，因为它是5.6，并且没有5.7的改进;-)）

Sysbench RO Distinct-Ranges 10Mx8-table UTF8mb4 on 2S 48cores-HT Skylake

---

评论：

• MySQL 8.0比5.7好30％
• MariaDB在这里做得很糟糕只是因为它在之前的latin1测试中已经做了一些不好的事情。

而不是摘要：

• 温和地提醒PeterZ，MySQL不是“仅限InnoDB”;-)）
• 如果你正在做“benchmarKeting” - 通过比较每个人与UTF8很容易成为“最好的”，并隐藏所有其他的回归和瓶颈.. ;-)）
• 所以，希望很明显为什么我的所有以下基准测试结果都只会以“latin1”发布。

转载http://dimitrik.free.fr/blog/archives/2018/04/mysql-performance-80-and-utf8-impact.html