Có cách nào để tối ưu truy vấn mariadb hơn không?

[Duy_Hoang98 (DS)]

bảng của em lưu đơn hàng, trong đó có các column id (primary key), service_id (int), status(varchar)
e index như ảnh (server_id, id_ctv đều là int nên em gộp cả 3 column vào 1 index dc ko nhỉ ? )

hiện tại bảng của em có khoảng 3 triệu dòng, engine InnoDB, khi em truy vấn
select * from orders where service_id=10 and status='inprocessing';

thì rất lâu khoảng vài chục giây mới ra kết quả (chỉ khoảng 10-100 rows)

còn đây ra kết quả khi e chạy explain:

khi select where id (primary key) thì rất nhanh. liệu có cách nào để truy vấn nhanh hơn ko ạ?

[Joe (Schwarz)]

You work with MariaDB, but it seems to me that you are afraid to read MariaDB documents in English. Get used to the fact that IT is English and if you don’t like English, your IT job is in jeopardy. Click HERE if you dare to read English.

[csdl (Hai Lúa)]

Hình như bạn không hiểu lắm về Index, đúng không? Không cần nhìn cái explain plan, với những index bạn đã tạo thì không ăn nhập gì với câu query cả. Tôi cũng không hiểu cái lý thuyết nào chỉ bạn các column cùng kiểu dữ liệu gom chung vô một index?

Với câu query như trên, bạn cần phải có index trên “service_id” và index trên “status”, hoặc một index cho cả 2 columns (service_id,status).

Đây là bài Hướng dẫn sử dụng Index trên SQL Server, mặc dù CSDL khác nhau, nhưng lý thuyết về Index là một.

[Duy_Hoang98 (DS)]

đúng r a, e k hiểu lắm về index. để e xem video kia xem. ngoài ra còn cách nào để tăng tốc truy vấn ko nhỉ a?( ko nói đến cpu, ram…)

[csdl (Hai Lúa)]

Về cơ bản thì để tăng tốc query, có những cách sau:

1. Hardware: Thêm RAM, thêm CPU, thay HDD bằng SSD có tốc độ cao hơn, tăng bandwidth mạng.
2. Database configuration: cấu hình DB sao cho sử dụng tối ưu resources, bỏ những cái không cần thiết (vd database thường thì không lý do gì cần encrypted, thậm chí một số DB không cần transaction log backup… ), phân bổ data files and log files trên những phân vùng phù hợp,…
3. Database replication, hot standby: dùng các kiểu replicate mà CSDL hổ trợ, route các câu lệnh query về hot standby.
4. Table partitioning: tùy theo application behavior, có thể partition table sao cho những phần thường được query chung nằng cùng partitions, những partitions này có thể đặt ở đĩa có IOPS cao hơn như SSD.
5. Index: trên những column trong điều kiện WHERE, JOIN,… lưu ý không phải khi nào Index cũng được xài, tùy theo các biểu thức điều kiện như AND/OR hoặc so sánh LIKE… đó là lý do tại sao phải cần xem execution plan.
6. Analytics: Database engine xây đượng execution plan dựa trên dữn liệu được lưu trong statistics, nếu đữ liệu này sai thì plan cũng sai => phải keep statistics up to date.
7. Rewrite query: Vấn đề không phải câu query dài hay ngắn mà là chạy nhanh hay chập, nhất là những câu query phức tạp như subquery cần phải lưu ý đặt WHERE ở đâu cho hợp lý, hay khi nào cần EXIST khi nào cần IN…
…

Nói chung để được performance tốt cần phải tối ư ở nhiều cấp, không phải chỉ Index là đủ! Đó là lý do tại sao phải học từ A-Z. Google hoặc chatgpt chỉ vá được vào chổ lủng chứ không làm ra nguyên cái áo

[Joe (Schwarz)]

All these known facts do not make the performance problems disappear. The reasons are manifold. However, all database files physically end up in some kind of indexed file where the data is retrieved via the primary key, the other auxiliary keys (alternate keys) are parts of the data as (abstract) keys and must be filtered out of the data heap (or record, if you like) for use. And that always takes some time. The more alternate keys are used for access, the worse the performance becomes. Like the memory leak, it is a CPU leak. No remedy, except upgrading to a more powerful computer.