MySQL: # 126 - Tệp khóa không chính xác cho bảng

Tôi gặp lỗi sau từ truy vấn MySQL.

#126 - Incorrect key file for table

Tôi thậm chí còn chưa khai báo khóa cho bảng này, nhưng tôi có các chỉ mục. Có ai biết những gì có thể là vấn đề?

Mỗi khi điều này xảy ra, theo kinh nghiệm của tôi, đó là một đĩa đầy đủ.

BIÊN TẬP

Cũng cần lưu ý rằng điều này có thể do đĩa ram đầy khi thực hiện những việc như thay đổi một bảng lớn nếu bạn đã định cấu hình đĩa ram. Bạn có thể tạm thời nhận xét dòng đĩa ram để cho phép các hoạt động như vậy nếu bạn không thể tăng kích thước của nó.

Trước hết, bạn nên biết rằng khóa và chỉ số là những từ đồng nghĩa trong MySQL. Nếu bạn xem tài liệu về Cú pháp TẠO BẢNG , bạn có thể đọc:

KEYthường là một từ đồng nghĩa với INDEX. Thuộc tính khóa PRIMARY KEYcũng có thể được chỉ định giống như KEYkhi được đưa ra trong định nghĩa cột. Điều này đã được thực hiện để tương thích với các hệ thống cơ sở dữ liệu khác.

Bây giờ, loại lỗi bạn đang gặp phải có thể do hai nguyên nhân:

• Sự cố đĩa trên máy chủ MySQL
• Khóa / bảng bị hỏng

Trong trường hợp đầu tiên, bạn sẽ thấy rằng việc thêm giới hạn vào truy vấn của mình có thể giải quyết vấn đề tạm thời. Nếu điều đó phù hợp với bạn, có thể bạn có một tmpthư mục quá nhỏ so với kích thước của các truy vấn mà bạn đang cố gắng thực hiện. Sau đó, bạn có thể quyết định hoặc làm tmplớn hơn hoặc thu nhỏ các truy vấn của bạn! ;)

Đôi khi, tmpđủ lớn nhưng vẫn bị đầy, bạn sẽ cần phải dọn dẹp thủ công trong những trường hợp này.

Trong trường hợp thứ hai, có những vấn đề thực tế với dữ liệu của MySQL. Nếu bạn có thể chèn lại dữ liệu một cách dễ dàng, tôi khuyên bạn chỉ nên thả / tạo lại bảng và chèn lại dữ liệu. Nếu bạn không thể, bạn có thể thử sửa chữa bảng tại chỗ với bảng REPAIR . Đó là một quá trình thường kéo dài và rất có thể thất bại.

Xem thông báo lỗi hoàn chỉnh mà bạn nhận được:

Tệp khóa không chính xác cho bảng 'FILEPATH.MYI'; cố gắng sửa chữa nó

Nó đề cập trong thông báo rằng bạn có thể cố gắng sửa chữa nó. Ngoài ra, nếu bạn nhìn vào FILEPATH thực tế mà bạn nhận được, bạn có thể tìm hiểu thêm:

• nếu nó giống như /tmp/#sql_ab34_23fvậy có nghĩa là MySQL cần tạo một bảng tạm thời vì kích thước truy vấn. Nó lưu trữ nó trong / tmp và không có đủ dung lượng trong / tmp của bạn cho bảng tạm thời đó.

• nếu nó chứa tên của một bảng thực thay thế, điều đó có nghĩa là bảng này rất có thể bị hỏng và bạn nên sửa chữa nó.

Nếu bạn xác định rằng sự cố của bạn là với kích thước / tmp, chỉ cần đọc câu trả lời này cho một câu hỏi tương tự để khắc phục: MySQL, Lỗi 126: Tệp khóa không chính xác cho bảng .

Làm theo các hướng dẫn này cho phép tôi tạo lại thư mục tmp của mình và khắc phục sự cố:

Hiển thị tất cả các hệ thống tệp và việc sử dụng đĩa của chúng ở dạng con người có thể đọc được:

df -h

Tìm các quy trình có tệp đang mở /tmp

sudo lsof /tmp/**/*

Sau đó, umount /tmpvà /var/tmp:

umount -l /tmp
umount -l /var/tmp

Sau đó, xóa tệp phân vùng bị hỏng:

rm -fv /usr/tmpDSK

Sau đó, tạo một cái mới đẹp:

/scripts/securetmp

Lưu ý rằng bằng cách chỉnh sửa tập lệnh securetmp Perl, bạn có thể tự đặt kích thước của thư mục tmp theo cách thủ công, tuy nhiên chỉ cần chạy tập lệnh đã tăng kích thước của thư mục tmp trên máy chủ của chúng tôi từ khoảng 450MB lên 4,0GB.

Lỗi # 126 thường xảy ra khi bạn có một bảng bị hỏng. Cách tốt nhất để giải quyết điều này là tiến hành sửa chữa. Bài viết này có thể giúp:

http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

Tôi gặp lỗi này khi đặt ft_min_word_len = 2trong my.cnfđó, điều này làm giảm độ dài từ tối thiểu trong chỉ mục văn bản đầy đủ xuống 2, từ mặc định là 4.

Sửa chữa bảng đã khắc phục sự cố.

Cố gắng sử dụng giới hạn trong truy vấn của bạn. Đó là vì đĩa đầy như đã nói bởi @Monsters X.

Tôi cũng đã đối mặt với vấn đề này và giải quyết theo giới hạn trong truy vấn, bởi vì hàng nghìn bản ghi đã ở đó. Hiện đang hoạt động tốt :)

Tôi biết rằng đây là một chủ đề cũ nhưng không có giải pháp nào được đề cập phù hợp với tôi. Tôi đã làm một cái gì đó khác có hiệu quả:

Bạn cần phải:

1. dừng dịch vụ MySQL:
2. Mở dữ liệu mysql \
3. Loại bỏ cả ib_logfile0 và ib_logfile1.
4. Khởi động lại dịch vụ

repair table myschema.mytable;

Tôi đã khắc phục sự cố này với:

ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;

Có thể giúp

• Refs: MySQL: ALTER IGNORE TABLE đưa ra "Vi phạm ràng buộc toàn vẹn"

Đi tới /etc/my.cnfvà bình luậntmpfs

#tmpdir=/var/tmpfs

Điều này khắc phục sự cố.

Tôi đã chạy lệnh được đề xuất trong một câu trả lời khác và trong khi thư mục nhỏ, nó trống, vì vậy không gian không phải là vấn đề.

/var/tmp$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs
/var/tmpfs$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs

Cố gắng chạy lệnh sửa chữa cho từng bảng có liên quan đến truy vấn.

Sử dụng quản trị viên MySQL, vào Danh mục -> Chọn Danh mục của bạn -> Chọn bảng -> Nhấp vào nút Bảo trì -> Sửa chữa -> Sử dụng FRM.

Bây giờ các câu trả lời khác đã giải quyết nó cho tôi. Hóa ra việc đổi tên một cột và một chỉ mục trong cùng một truy vấn đã gây ra lỗi.

Không làm việc:

-- rename column and rename index
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

Tác phẩm (2 câu):

-- rename column
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
-- rename index
ALTER TABLE `client_types`
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

Đây là trên MariaDB 10.0.20. Không có lỗi nào với cùng một truy vấn trên MySQL 5.5.48.

mysql> set global sql_slave_skip_counter=1; start slave; show slave status\G

Sau đó, có lỗi tồn tại:

 Error 'Table './openx/f_scraper_banner_details' is marked as crashed and should be repaired' on query. Default database: 'openx'. Query: 'INSERT INTO f_scraper_banner_details(job_details_id, ad_id, client_id, zone_id, affiliateid, comments, pct_to_report, publisher_currency, sanity_check_enabled, status, error_code, report_date) VALUES (10274859, 321264, 0, 31926, 0, '', -1, 'USD', 1, 'FAILURE', 'INACTIVE_BANNER', '2016-06-28 04:00:00')'

mysql> sửa chữa bảng f_scraper_banner_details;

Điều này đã làm việc cho tôi

Vấn đề của tôi đến từ một truy vấn sai. Tôi đã tham chiếu một bảng trong FROM, không được tham chiếu trong SELECT.

thí dụ:

   SELECT t.*,s.ticket_status as `ticket_status`
   FROM tickets_new t, ticket_status s, users u

, users ulà những gì đã gây ra vấn đề cho tôi. Xóa đã giải quyết được vấn đề.

Để tham khảo, điều này nằm trong môi trường nhà phát triển CodeIgniter.

Tôi nhận được thông báo này khi ghi vào bảng sau khi giảm ft_min_word_len (độ dài từ tối thiểu của toàn văn bản). Để giải quyết nó, hãy tạo lại chỉ mục bằng cách sửa chữa bảng.

mysqlcheck -r -f -uroot -p --use_frm db_name

thường sẽ làm thủ thuật