Hiệu suất so sánh SQL sử dụng chuỗi con vs giống với ký tự đại diện

Question

Tôi đang làm việc trên điều kiện kết hợp giữa 2 bảng trong đó một trong các cột khớp với nhau là một giá trị tương ứng. Tôi cần phải tham gia columnA từ tableA đến 2 ký tự đầu tiên của cộtB từ tableB.

Tôi đã phát triển 2 câu lệnh khác nhau để xử lý điều này và tôi đã cố gắng phân tích hiệu suất của từng phương pháp.

Phương pháp 1:

ON tB.columnB like tA.columnA || '%' 

Cách 2:

ON substr(tB.columnB,1,2) = tA.columnA 

Kế hoạch thực hiện truy vấn có bước ít hơn rất nhiều sử dụng Phương pháp 1 so với Phương pháp 2, tuy nhiên, có vẻ như Phương pháp 2 thực hiện nhiều nhanh hơn. Ngoài ra, kế hoạch thực hiện cho thấy chỉ mục được đề xuất cho Phương pháp 2 có thể cải thiện hiệu suất của nó.

Tôi đang chạy tính năng này trên IBM iSeries, mặc dù sẽ quan tâm đến các câu trả lời theo nghĩa chung để tìm hiểu thêm về tối ưu hóa truy vấn sql.

Có nghĩa là Phương pháp 2 sẽ thực thi nhanh hơn không?

Câu hỏi SO này tương tự, nhưng có vẻ như không ai cung cấp bất kỳ câu trả lời cụ thể nào về hiệu suất của các phương pháp này: T-SQL speed comparison between LEFT() vs. LIKE operator.

PS: Thiết kế bảng yêu cầu loại tham gia này không phải là thứ tôi có thể thay đổi vào lúc này. Tôi nhận ra rằng các trường được phân cách giữ các loại dữ liệu khác nhau sẽ thích hợp hơn.

Answer 1

Tôi tìm thấy tham chiếu này trong sách đỏ của IBM liên quan đến hiệu suất SQL. Có vẻ như chức năng vô hướng SUBSTR có thể được xử lý một cách tối ưu bởi một iSeries.

Nếu bạn tìm kiếm các ký tự đầu tiên và muốn sử dụng SQE thay của CQE, bạn có thể sử dụng chức năng chuỗi vô hướng vào dấu trái của dấu bằng. Nếu bạn phải tìm kiếm các ký tự bổ sung trong chuỗi, bạn cũng có thể sử dụng chức năng vô hướng POSSTR. Bằng cách chia thuộc tính LIKE thành nhiều hàm vô hướng, bạn có thể ảnh hưởng đến trình tối ưu hóa truy vấn để sử dụng SQE.

http://publib-b.boulder.ibm.com/abstracts/sg246654.html?Open

Answer 2

Có, Phương pháp 2 sẽ nhanh hơn. LIKE không phải là một chức năng hiệu quả.

Để so sánh hiệu suất của các kỹ thuật khác nhau, hãy thử sử dụng Visual Explain. Bạn sẽ tìm thấy nó bị chôn vùi trong System i Navigator. Trong kết nối hệ thống của bạn, mở rộng cơ sở dữ liệu, sau đó bấm vào tên RDB của bạn. Trong khung bên phải phía dưới, bạn có thể bấm vào tùy chọn để chạy một tập lệnh SQL. Nhập vào câu lệnh SELECT của bạn và chọn tùy chọn trình đơn cho Giải thích trực quan hoặc Chạy và giải thích. Giải thích trực quan sẽ phá vỡ kế hoạch thực hiện cho bảng sao kê của bạn và hiển thị cho bạn chi phí cho từng phần như được ước tính trên các bảng của bạn với các chỉ mục có sẵn.

Answer 3

Tôi chạy sau trong Cố vấn SQL trong IBM Data Studio trên một trong các bảng trong LUW DB2 của tôi 10.1 cơ sở dữ liệu:

SELECT * 
FROM PDM.DB30 
WHERE DB30_SYSTEM_ID = 'XXX' 
    AND DB30_VERSION_ID = 'YYY' 
    AND SUBSTR(DB30_REL_TABLE_NM, 1, 4) = 'ZZZZ' 

và

SELECT * 
FROM PDM.DB30 
WHERE DB30_SYSTEM_ID = 'XXX' 
    AND DB30_VERSION_ID = 'YYY' 
    AND DB30_REL_TABLE_NM LIKE 'ZZZZ%' 

Cả hai đều có cùng một con đường truy cập chính xác sử dụng các chỉ số tương tự, ước tính cùng chi phí IO và cardinality ước tính tương tự, sự khác biệt chỉ được ước tính tổng số CPU chi phí cho LIKE là 178,343,75 trong khi SUBSTR là 197,518,48 (chênh lệch 10%).

Tổng chi phí tích lũy cho cả hai đều giống nhau, do đó, sự khác biệt này là không đáng kể theo cố vấn.

Answer 4

Bạn thực sự có thể chạy với các ví dụ thực trong cơ sở dữ liệu của mình.

LIKE luôn chạy tốt hơn.

select count(*) from u_log where log_text like 'AUT%'; 
1 row(s) returned : 90ms taken 

select count(*) from u_log where substr(log_text,1,3)='AUT'; 
1 row(s) returned : 493ms taken