MySQL:chỉ mục tổng hợp fulltext + btree?

Sử dụng IN BOOLEAN MODE .

Chỉ mục ngày không hữu ích. Không có cách nào để kết hợp hai chỉ mục.

Hãy lưu ý, nếu người dùng tìm kiếm thứ gì đó hiển thị trong 30 nghìn hàng, truy vấn sẽ chậm. Không có gì đơn giản xung quanh nó.

Tôi nghi ngờ bạn có TEXT cột trong bảng? Có như vậy thì mới có hy vọng. Thay vì làm SELECT * một cách mù quáng , trước tiên hãy tìm id và lấy LIMIT đã áp dụng, sau đó thực hiện * .

SELECT a.* 
    FROM tbl AS a
    JOIN ( SELECT date, id
             FROM tbl
             WHERE MATCH(...) AGAINST (...)
             ORDER BY date DESC
             LIMIT 10 ) AS x
        USING(date, id)
    ORDER BY date DESC;

Cùng với

PRIMARY KEY(date, id),
INDEX(id),
FULLTEXT(...)

Công thức và lập chỉ mục này sẽ hoạt động như sau:

Sử dụng FULLTEXT để tìm 30 nghìn hàng, phân phối PK.
Với PK, sắp xếp 30K hàng theo date .
Chọn 10 cuối cùng, gửi date, id
Quay lại bàn 10 lần bằng PK.
Sắp xếp lại. (Vâng, điều này là cần thiết.)

Thêm (Trả lời rất nhiều Bình luận):

Mục tiêu đằng sau việc định dạng lại của tôi là tránh tìm nạp tất cả cột của 30K hàng. Thay vào đó, nó chỉ tìm nạp PRIMARY KEY , sau đó giảm khoảng cách đó xuống 10, sau đó tìm nạp * chỉ có 10 hàng. Ít thứ hơn nhiều.

Liên quan đến COUNT trên bảng InnoDB:

INDEX (col) làm cho nó trở thành một chỉ mục quét hoạt động cho SELECT COUNT(*) hoặc SELECT COUNT(col) không có WHERE .
Không có INDEX(col), SELECT COUNT (*) will use the "smallest" index; but SELECT COUNT (col) `sẽ cần một bảng quét.
Quét bảng là thường chậm hơn quét chỉ mục.
Cẩn thận về thời gian - Nó bị ảnh hưởng đáng kể bởi liệu chỉ mục và / hoặc bảng đã được lưu vào bộ nhớ cache trong RAM hay chưa.

Một điều khác về FULLTEXT là + ở phía trước của các từ - để nói rằng mỗi từ phải tồn tại, khác không có sự phù hợp. Điều này có thể cắt giảm 30 nghìn.

FULLTEXT chỉ mục sẽ cung cấp date, id là thứ tự ngẫu nhiên, không phải thứ tự PK. Dù sao, việc cho rằng bất kỳ thứ tự nào là 'sai', do đó, việc thêm ORDER BY là 'đúng' , sau đó hãy để Trình tối ưu hóa ném nó nếu nó biết rằng nó là thừa. Và đôi khi Trình tối ưu hóa có thể tận dụng ORDER BY (không phải trong trường hợp của bạn).

Chỉ xóa ORDER BY , trong nhiều trường hợp, làm cho một truy vấn chạy nhanh hơn nhiều. Điều này là do nó tránh tìm nạp, chẳng hạn như 30K hàng và sắp xếp chúng. Thay vào đó, nó chỉ phân phối 10 hàng "bất kỳ".

(Tôi chưa có kinh nghiệm với Postgres, vì vậy tôi không thể giải quyết câu hỏi đó.)