Vì bạn không kiểm soát thuật toán đã chọn, không có cách nào để biết trực tiếp. Tuy nhiên, không có chỉ mục, SELECT phải là O (n) (quét bảng phải kiểm tra mọi bản ghi, nghĩa là nó sẽ chia tỷ lệ với kích thước của bảng).
Với một chỉ mục, SELECT có thể là O (log (n)) (mặc dù nó sẽ phụ thuộc vào thuật toán được sử dụng để lập chỉ mục và các thuộc tính của chính dữ liệu nếu điều đó đúng với bất kỳ bảng thực nào). Để xác định kết quả của bạn cho bất kỳ bảng hoặc truy vấn nào, bạn phải sử dụng đến cấu hình dữ liệu thế giới thực để chắc chắn.
INSERT không có chỉ mục sẽ rất nhanh (gần với O (1)) trong khi UPDATE cần tìm các bản ghi trước và do đó sẽ chậm hơn (một chút) so với SELECT đưa bạn đến đó.
INSERT với các chỉ mục có thể sẽ lại nằm trong ballpark của O (log (n ^ 2)) khi cây chỉ mục cần được cân bằng lại, gần với O (log (n)) hơn. Sự chậm lại tương tự sẽ xảy ra với CẬP NHẬT nếu nó ảnh hưởng đến các hàng được lập chỉ mục, trên chi phí CHỌN.
Tất cả các cược sẽ tắt khi bạn nói về JOIN trong hỗn hợp:bạn sẽ phải lập hồ sơ và sử dụng các công cụ ước tính truy vấn cơ sở dữ liệu của mình để đọc về nó. Cũng lưu ý rằng nếu truy vấn này là quan trọng về hiệu suất, bạn nên re hồ sơ theo thời gian vì các thuật toán được sử dụng bởi trình tối ưu hóa truy vấn của bạn sẽ thay đổi khi tải dữ liệu thay đổi.
Một điều khác cần lưu ý ... big-O không cho bạn biết về chi phí cố định cho mỗi giao dịch. Đối với các bảng nhỏ hơn, chúng có thể cao hơn chi phí làm việc thực tế. Ví dụ:chi phí thiết lập, chia nhỏ và giao tiếp của truy vấn mạng chéo cho một hàng chắc chắn sẽ nhiều hơn so với việc tra cứu bản ghi được lập chỉ mục trong một bảng nhỏ.
Vì điều này, tôi nhận thấy rằng việc có thể nhóm một nhóm các truy vấn có liên quan trong một lô có thể có tác động lớn hơn đến hiệu suất so với bất kỳ tối ưu hóa nào tôi đã thực hiện đối với cơ sở dữ liệu thích hợp.
