Tôi hiện đang cố gắng chạy một số truy vấn đối với kết xuất dữ liệu của các bình luận của Stack Overflow. Đây là lược đồ trông như thế nào:

CREATE TABLE `socomments` (
  `Id` int(11) NOT NULL,
  `PostId` int(11) NOT NULL,
  `Score` int(11) DEFAULT NULL,
  `Text` varchar(600) NOT NULL,
  `CreationDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `UserId` int(11) NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `idx_socomments_PostId` (`PostId`),
  KEY `CreationDate` (`CreationDate`),
  FULLTEXT KEY `Text` (`Text`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Tôi đã chạy truy vấn này trên bảng và nó chạy rất chậm (Nó có 29 triệu hàng, nhưng nó có chỉ mục Toàn văn):

SELECT *
FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)

Vì vậy, tôi đã mô tả nó, kết quả của nó là:

|| Status                     || Duration ||
|| starting                   || 0.000058 ||
|| checking permissions       || 0.000006 ||
|| Opening tables             || 0.000014 ||
|| init                       || 0.000019 ||
|| System lock                || 0.000006 ||
|| optimizing                 || 0.000007 ||
|| statistics                 || 0.000013 ||
|| preparing                  || 0.000005 ||
|| FULLTEXT initialization    || 207.1112 ||
|| executing                  || 0.000009 ||
|| Sending data               || 0.000856 ||
|| end                        || 0.000004 ||
|| query end                  || 0.000004 ||
|| closing tables             || 0.000006 ||
|| freeing items              || 0.000059 ||
|| logging slow query         || 0.000037 ||
|| cleaning up                || 0.000046 ||

Như bạn có thể thấy, nó dành một thời gian dài để khởi tạo FULLTEXT. Điều này có bình thường không? Nếu không, tôi sẽ sửa nó như thế nào?

Những người khác đã tìm thấy một tình huống rắc rối

• InnoDB Tìm kiếm toàn văn trong MySQL 5.6: Phần 3, Hiệu suất
• InnoDB Tìm kiếm toàn văn bản với MỞ RỘNG rất chậm
  • Ngày 16 tháng 9 năm 2010
  • 5.0,51a, 5.0,75, 5,0 bzr
  • Tình trạng: Không có phản hồi
• Truy vấn CHỌN treo trong trạng thái khởi tạo FULLTEXT
  • Ngày 17 tháng 10 năm 2014
  • MySQL 5.6.19
  • Tình trạng: Không sửa

Vì Tài liệu MySQL rất ngắn gọn về trạng thái luồng này

Khởi tạo FULLTEXT

Máy chủ đang chuẩn bị thực hiện tìm kiếm toàn văn bản bằng ngôn ngữ tự nhiên.

cách duy nhất của bạn là chuẩn bị với ít dữ liệu hơn. Làm sao ?

BỀN VỮNG # 1

Nhìn vào truy vấn của bạn một lần nữa. Nó đang chọn tất cả các cột. Tôi sẽ cấu trúc lại truy vấn để chỉ thu thập các cột id từ đó socomments. Sau đó, tham gia những id được truy xuất trở lại socommentsbảng.

SELECT B.* FROM
(SELECT id FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)) A
LEFT JOIN socomments B USING (id);

Điều này có thể tạo ra một kế hoạch GIẢI THÍCH xấu hơn nhưng tôi nghĩ rằng hồ sơ sẽ thay đổi tốt hơn. Ý tưởng cơ bản là: Nếu bạn có Tìm kiếm FULLTEXT tích cực, hãy làm cho nó thu thập ít dữ liệu nhất trong FULLTEXT initializationgiai đoạn đó, do đó giảm thời gian.

Tôi đã đề nghị điều này nhiều lần trước đây

• May 14, 2012: truy vấn chậm với fulltext và tham gia trái
• Mar 18, 2012: Tại sao THÍCH nhanh hơn gấp 4 lần so với MATCH ... CHỐNG LẠI trên chỉ mục FULLTEXT trong MySQL?
• Jan 26, 2012: Mysql fulltext tìm kiếm tối ưu hóa my.cnf :
• Oct 25, 2011: Chỉ mục FULLTEXT bị bỏ qua trong CHẾ ĐỘ BOOLESE với 'số lượng từ' có điều kiện

BỀN VỮNG # 2

Vui lòng đảm bảo rằng bạn đang đặt các tùy chọn FULLTEXT dựa trên InnoDB, chứ không phải các tùy chọn cho MyISAM. Hai lựa chọn bạn nên quan tâm là

• innodb_ft_cache_size
  • Giá trị Def 8000000 (7.629M)
  • Giá trị tối đa 80000000 (76,29M)
• innodb_ft_total_cache_size
  • Giá trị Def 640000000 (610M)
  • Giá trị tối đa 1600000000 (1525M = 1.49G)

Nghĩ về nó ngay lúc này. Trường văn bản là VARCHAR (600). Nói trung bình là 300 byte. Bạn có 29.000.000 triệu trong số họ. Đó sẽ là một chút của 8GB. Có lẽ việc tăng innodb_ft_cache_size và innodb_ft_total_cache_size cũng có thể giúp ích.

Đảm bảo bạn có đủ RAM cho bộ đệm InnoDB FULLTEXT lớn hơn.

HÃY THỬ MỘT LẦN !!!

Nếu bạn đang sử dụng các chỉ mục InnoDB FULLTEXT, các truy vấn sẽ thường bị treo ở trạng thái "Khởi tạo FULLTEXT" nếu bạn đang truy vấn một bảng có số lượng lớn các hàng bị xóa. Trong triển khai FULLTEXT của InnoDB, các hàng đã xóa sẽ không được cắt xén cho đến khi một thao tác TỐI ƯU tiếp theo được chạy với bảng bị ảnh hưởng. Xem: https://dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html

Để xóa các mục nhập chỉ mục toàn văn bản cho các bản ghi bị xóa, bạn phải chạy TỐI ƯU BẢNG trên bảng được lập chỉ mục với innodb_optizes_fulltext_only = ON để xây dựng lại chỉ mục toàn văn bản.

Người ta cũng có thể kiểm tra số lượng hồ sơ đã xóa nhưng không bị xóa bằng cách truy vấn information_schema.innodb_ft_delatted

Để giải quyết vấn đề này, người ta nên thường xuyên chạy BẢNG TỐI ƯU đối với các bảng có chỉ mục InnoDB FULLTEXT.

Có một lỗi đã được xác nhận trong MySQL ( DOCID đã xóa không được duy trì trong quá trình TỐI ƯU của các bảng InnoDB FULLTEXT ) làm tăng hiệu suất trong các lần xóa nặng (mà không xây dựng lại bảng từ đầu).

Liên quan .

Các chỉ mục toàn văn bản trong MySQL không được thiết kế để hỗ trợ một lượng lớn dữ liệu nên tốc độ tìm kiếm giảm xuống khá nhanh khi dữ liệu của bạn đang tăng lên. Một trong những giải pháp là sử dụng các công cụ tìm kiếm toàn văn bản bên ngoài như Solr hoặc Sphinx đã cải thiện chức năng tìm kiếm (hỗ trợ điều chỉnh cụm từ và hỗ trợ tìm kiếm cụm từ, khía cạnh tích hợp, đoạn trích, v.v.) cú pháp truy vấn mở rộng và tốc độ nhanh hơn nhiều vào giữa bộ dữ liệu lớn.

Solr dựa trên nền tảng Java, vì vậy nếu bạn chạy ứng dụng dựa trên Java sẽ là lựa chọn tự nhiên cho bạn, Sphinx được viết trên C ++ và hoạt động như một daemon theo cùng kiểu với MySQL. Ngay khi bạn cung cấp công cụ bên ngoài với dữ liệu bạn muốn tìm kiếm, bạn cũng có thể di chuyển một số truy vấn ra khỏi MySQL. Tôi không thể cho bạn biết công cụ nào tốt hơn trong trường hợp của bạn, tôi chủ yếu sử dụng Sphinx và đây là ví dụ sử dụng: http://astellar.com/2011/12/replaces-mysql-full-text-search-with-sphinx/