Tôi không nhận được điều này.

Tôi đã có một bảng với các chỉ mục này

PRIMARY     post_id
INDEX       topic_id
FULLTEXT    post_text

Bảng có (chỉ) 346 000 hàng. Tôi đang cố gắng thực hiện 2 truy vấn.

SELECT post_id 
FROM phpbb_posts 
WHERE topic_id = 144017 
AND post_id != 155352 
AND MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar')

mất 4,05 giây trong khi

SELECT post_id 
FROM phpbb_posts 
WHERE topic_id=144017 
AND post_id != 155352 
AND post_text LIKE ('%http://rapidshare.com/files/5494794/photo.rar%')

mất 0,027 giây.

GIẢI THÍCH cho thấy rằng sự khác biệt duy nhất là ở khả fulltextnăng_key ( đã bao gồm postSphere, LIKEkhông)

Điều đó thực sự kỳ lạ.

Điều gì đằng sau điều này? Điều gì đang xảy ra trong nền? Làm thế nào có LIKEthể nhanh như vậy khi không sử dụng chỉ mục và FULLTEXT rất chậm khi sử dụng chỉ mục của nó?

CẬP NHẬT1:

Trên thực tế, bây giờ mất khoảng 0,5 giây, có thể bảng đã bị khóa, nhưng vẫn vậy, khi tôi bật hồ sơ, điều đó cho thấy rằng KHỞI TẠO FULLTEXT mất 0,2 giây. Có chuyện gì vậy?

Tôi có thể truy vấn bảng của mình với LIKE10 lần một giây, với toàn văn chỉ 2 lần

CẬP NHẬT2:

Sự ngạc nhiên!

mysql> SELECT post_id FROM phpbb_posts WHERE post_id != 2 AND topic_id = 6 AND MATCH(post_text) AGAINST ('rapidshare.com');
Empty set (0.04 sec)

Vì vậy, tôi hỏi, làm thế nào là có thể?

Ngoài ra,

SELECT count(*) FROM phpbb_posts WHERE MATCH(post_text) AGAINST ('rapidshare.com')

thực sự rất chậm Có thể fulltext bất kỳ bị hỏng?

CẬP NHẬT3:

Cái quái gì thế?

SELECT forum_id, post_id, topic_id, post_text  FROM phpbb_posts  WHERE MATCH(post_text) AGAINST ('rapidshare.com') LIMIT 0, 30;

mất 0,27 giây trong khi

SELECT count(*) FROM phpbb_posts  WHERE MATCH(post_text) AGAINST ('rapidshare.com') LIMIT 0, 30;

mất hơn 30 giây! Điều gì đang xảy ra ở đây?

Tôi nghĩ vấn đề có thể xuất phát từ sự hiện diện của chính chỉ số FULLTEXT.

Mỗi khi có một truy vấn liên quan đến chỉ mục FULLTEXT, Trình tối ưu hóa truy vấn MySQL có xu hướng đưa truy vấn vào quét toàn bộ bảng. Tôi đã thấy điều này trong những năm qua. Tôi cũng đã viết một bài viết trước đó về hành vi rắc rối nhất này trong các chỉ mục FULLTEXT .

Bạn có thể cần làm hai việc:

1. cấu trúc lại truy vấn để chỉ mục FULLTEXT không ném Trình tối ưu hóa truy vấn MySQL vào trạng thái nhầm lẫn
2. Thêm một chỉ mục bổ sung sẽ hỗ trợ chính xác truy vấn được cấu trúc lại

REFACTOR THE QUERY

Đây là truy vấn ban đầu của bạn

SELECT post_id  
FROM phpbb_posts  
WHERE topic_id = 144017  
AND post_id != 155352  
AND MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar') 

Bạn sẽ cần cấu trúc lại truy vấn như thế này:

SELECT subqueryA.post_id
FROM
(
    SELECT post_id FROM phpbb_posts
    WHERE topic_id = 144017
    AND post_id != 155352
) subqueryA
INNER JOIN
(
    SELECT post_id FROM phpbb_posts
    WHERE MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar')
) subqueryB
USING (post_id);

TẠO MỘT INDEX MỚI

Bạn sẽ cần một chỉ số để hỗ trợ subqueryA. Bạn đã có một chỉ mục trên topic_id. Bạn cần thay thế nó như sau:

ALTER TABLE phpbb_posts ADD INDEX topic_post_ndx (topic_id,post_id);
ALTER TABLE phpbb_posts DROP INDEX topic_id;

Hãy thử một lần !!!

CẬP NHẬT 2012/03/19 13:08 EDT

Hãy thử cái này trước

SELECT post_id FROM
(
    SELECT * FROM phpbb_posts
    WHERE topic_id = 144017
    AND post_id != 155352
) A;

Nếu điều này chạy nhanh và trả về một số lượng nhỏ hàng, thì hãy thử truy vấn con lồng nhau này:

SELECT post_id FROM
(
    SELECT * FROM phpbb_posts
    WHERE topic_id = 144017
    AND post_id != 155352
) A
WHERE MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar');

CẬP NHẬT 2012/03/19 13:11 EDT

So sánh thời gian chạy này:

SELECT count(*) FROM phpbb_posts  WHERE MATCH(post_text) AGAINST ('rapidshare.com') LIMIT 0, 30;

Với cái này

SELECT count(*) FROM phpbb_posts WHERE 1 = 1;

Nếu có thời gian chạy là như nhau, thì mệnh đề MATCH đang được thực thi trên mỗi hàng. Như tôi đã đề cập trước đó, sử dụng các chỉ mục FULLTEXT có xu hướng vô hiệu hóa bất kỳ lợi ích nào được cố gắng và đóng góp bởi Trình tối ưu hóa truy vấn MySQL.