Wordpress 使用 varchar(255) 作為 InnoDB 和 utf8mb4_unicode_ci 的索引？
我正在嘗試更多地了解正確數據庫建構的細節，並遇到了一些讓我感到困惑的事情。在目前的 Wordpress 安裝中，我發現用於索引的 varchar 欄位長於 191 個字元，文件似乎說這是最大值。我正在執行 MariaDB 10.x，我認為它與 MySQL 5.7 匹配，並且文件確認了使用 utf8mb4_unicode_ci 排序規則和緊湊作為格式時的限制。
我正在查找 varchar(200) 和 varchar(255) 索引欄位，例如 wp_postmeta，欄位 meta_key 是 varchar(255)。我錯了還是對此感到困惑？數據庫正在使用 InnoDB 引擎。感謝您的任何澄清。
（這個答案可能比你想要的要多。它是對問題根源的深入討論，以及多種解決方案。）
很久以前，當 MySQL 添加 時，每個字元
CHARACTER SET utf8最多需要 3個字節。並且索引被限制為 767字節，對於.VARCHAR(255)添加時
utf8mb4（因為utf8不完整），編碼需要最多4個字節/字元，但索引限制沒有增加。（糟糕。）因此，索引（對於 utf8mb4）被限制為 191個字元（（767-2）/4）。這個問題一直持續到 5.5 和 5.6（MariaDB 5.5 - 10.1？）。5.7 收拾東西。
這個問題有很多解決方案：
- 改回
utf8. 大多數使用者可以擺脫這一點。但是，如果您需要 Emoji 或所有中文，則需要utf8mb4.- 將您的索引限制
VARCHARs為 191 而不是 255。這通常可以安全地完成，但您應該檢查數據，並了解它限制了您可以使用的字元串。- （見 jkavalik 的評論）使用“前綴”索引：
INDEX (col(191))。這有兩個負面影響：（1）如果索引是真的UNIQUE，你會得到對唯一性約束的錯誤解釋。(2)由於前綴效率低下，性能可能會受到影響。- 在 5.5.14、5.6.3、5.7.7、MariaDB 5.5 中，以下組合將限制從 767 提高到 3072：（
innodb_large_prefix=1在 5.7.7 中預設啟用）innodb_file_format=Barracuda、、、=或。innodb_file_per_table=1``ROW_FORMAT``DYNAMIC``COMPRESSED如果 WordPress 主動解決您遇到的問題，那就太好了。
（更新）在以後的版本中，這些已被棄用（5.7 和 10.2？） ，因為它們不再是必需的：
innodb_file_format、innodb_file_format_check和. 如果您收到有關該效果的錯誤，請不要費心設置它們。它們實際上在 8.0 / 10.4(?)innodb_file_format_max``innodb_large_prefix