Tại sao lỗi này xảy raÍt có điều gì gây khó chịu hơn một lỗi cơ sở dữ liệu ngăn cản việc cài đặt WordPress mới. Thông thường, nó xảy ra ngay khi bạn sắp hoàn tất. Bạn sẽ thấy ERROR 1071 (42000) hiện lên, báo hiệu rằng cơ sở dữ liệu của bạn đã chạm giới hạn khi cố gắng tạo một index (chỉ mục). Điều này thường xảy ra khi kích hoạt các plugin tiêu tốn nhiều tài nguyên như WooCommerce hoặc Yoast SEO trên các môi trường máy chủ cũ.
ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes
Phép toán đằng sau giới hạn nàyTất cả nằm ở một phép tính đơn giản. WordPress hiện đại sử dụng bảng mã utf8mb4 để hỗ trợ emoji và các ký hiệu đặc biệt. Trong định dạng này, mỗi ký tự có thể chiếm tới 4 byte dung lượng.
Khi một plugin cố gắng tạo một index duy nhất trên cột VARCHAR(255), cơ sở dữ liệu sẽ tính toán: 255 ký tự × 4 byte = 1.020 byte. Vì các phiên bản cũ của công cụ InnoDB (trước MySQL 5.7.7) có giới hạn nghiêm ngặt 767 byte cho các khóa index, cơ sở dữ liệu sẽ từ chối truy vấn. Về cơ bản, nó giống như việc cố gắng nhét một khối 1.020 byte vào một cái lỗ chỉ rộng 767 byte.
Cách sửa 1: Bật InnoDB Large Prefix (Tốt nhất cho người dùng VPS)Nếu bạn tự quản lý máy chủ của mình qua SSH, bạn có thể khắc phục điều này bằng cách thay đổi cách cơ sở dữ liệu xử lý định dạng tệp. Bạn cần chuyển sang định dạng Barracuda, định dạng này hỗ trợ các khóa index lên đến 3.072 byte.
1. Truy cập cơ sở dữ liệu```
mysql -u root -p
### 2. Cập nhật các biến toàn cụcChạy các lệnh sau để yêu cầu hệ thống cho phép các tiền tố (prefix) lớn hơn:
SET GLOBAL innodb_file_format = Barracuda; SET GLOBAL innodb_file_per_table = ON; SET GLOBAL innodb_large_prefix = ON;
### 3. Lưu các thay đổi vĩnh viễnĐừng bỏ qua bước này, nếu không lỗi sẽ quay trở lại sau lần khởi động lại tiếp theo. Mở tệp cấu hình của bạn (thường là `/etc/mysql/my.cnf`) và thêm các dòng sau vào dưới khối `[mysqld]`:
[mysqld] innodb_file_format = Barracuda innodb_file_per_table = ON innodb_large_prefix = ON
Khởi động lại dịch vụ để áp dụng các thay đổi: `sudo systemctl restart mysql`.
## Cách sửa 2: Điều chỉnh wp-config.php (Tốt nhất cho Shared Hosting)Nếu bạn đang sử dụng hosting chia sẻ (như Bluehost hoặc HostGator), có lẽ bạn không có quyền root để thay đổi các biến máy chủ. Thay vào đó, bạn có thể yêu cầu WordPress sử dụng bảng mã 3-byte. Điều này giúp giảm kích thước index xuống còn **255 × 3 = 765 byte**, vừa vặn dưới giới hạn 767 byte.
Mở tệp `wp-config.php` của bạn và tìm dòng này:
define( 'DB_CHARSET', 'utf8mb4' );
Thay đổi nó thành:
define( 'DB_CHARSET', 'utf8' );
**Cảnh báo:** Chuyển sang `utf8` có nghĩa là bạn sẽ mất khả năng hỗ trợ emoji đầy đủ. Nếu người dùng đăng emoji 😭, nó có thể hiển thị dưới dạng ký tự bị lỗi hoặc dấu chấm hỏi.
## Cách sửa 3: Rút ngắn độ dài Index thủ côngĐôi khi bạn chỉ cần sửa một bảng cụ thể. Bạn có thể thay đổi cột một cách thủ công để sử dụng 191 ký tự thay vì 255. Vì **191 × 4 = 764 byte**, cơ sở dữ liệu sẽ chấp nhận nó mà không phàn nàn gì.
ALTER TABLE wp_options MODIFY option_name varchar(191);
Kiểm tra nhật ký lỗi (error log) để xem bảng và cột cụ thể nào đã gây ra lỗi 1071, sau đó thay thế `wp_options` và `option_name` bằng các tên tìm thấy trong nhật ký của bạn.
## Cách kiểm tra kết quảĐể đảm bảo mọi thứ hoạt động trơn tru, hãy kiểm tra lại công việc của bạn:
- **Đối với VPS:** Chạy `SHOW VARIABLES LIKE 'innodb_large_prefix';`. Nếu kết quả là `ON`, bạn đã thành công.- **Đối với Shared Hosting:** Xóa các bảng đang tạo dở dang khỏi cơ sở dữ liệu và bắt đầu lại quá trình cài đặt WordPress. Bây giờ nó sẽ hoàn tất mà không có lỗi.- **Kiểm tra Plugin:** Thử kích hoạt lại plugin đã gây ra sự cố. Bây giờ nó sẽ tạo các bảng thành công.Mặc dù các cách sửa lỗi này có hiệu quả, nhưng giới hạn 767-byte là dấu hiệu của một máy chủ đã cũ. Để có bảo mật và hiệu suất tốt nhất, hãy lập kế hoạch nâng cấp lên **MySQL 8.0** hoặc **MariaDB 10.5+**, nơi các giới hạn này không còn là vấn đề nữa.