我像大多数开发人员一样使用索引(主要是……嗯!索引),但我确信有很多微妙的方法可以使用索引来优化数据库。我不确定它是否特定于 DBMS 的任何实现。
我的问题是:什么是如何使用索引的好例子(除了基本的、明显的情况),以及当您在表上指定索引时 DBMS 如何优化其数据库?
ran*_*omx 11
将索引视为“目录”......这是指向文件中位置的指针的有序列表,也就是偏移量。假设您在一个表中存储了数百万条记录,而不是在表中搜索匹配条件,引用有序列表进行匹配要快得多,然后将指针堆叠到特定的匹配行。索引的一个完美示例是表主键字段,最典型的是它的“id”字段。如果您想要行 id # 11234566,那么向索引请求指向数据的指针要比扫描数据源的位置 11234566 快得多。
这是索引的一个不那么明显的用法:
CREATE TABLE activity_log (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
activity_type_id SMALLINT UNSIGNED NOT NULL,
datetime_created DATETIME
KEY(activity_type_id),
PRIMARY KEY(id)
);
CREATE TABLE activity_log_to_date_key (
activity_log_id INT UNSIGNED NOT NULL,
date_created_key INT UNSIGNED NOT NULL REFERENCES dim_datetime(id),
UNIQUE KEY(activity_log_id),
KEY(date_created_key)
);
CREATE TABLE dim_datetime (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
date_hour DATETIME NOT NULL,
PRIMARY KEY(id),
KEY(date_hour)
);
Run Code Online (Sandbox Code Playgroud)
您的操作可以创建您的日志记录,然后创建对索引日期时间的引用,该索引日期时间比您的日志表搜索/排序更快。然后在它自己的主键上加入你的日志表。如果您需要我对此进行扩展,请告诉我。我希望这是有道理的。
示例查询:
SELECT a.activity_log_id, al.activity_type_id, al.datetime_created
FROM activity_log_to_date_key a
INNER JOIN dim_datetime d ON (d.id = a.date_created_key)
LEFT JOIN activity_log al ON (al.id = a.activity_log_id)
WHERE d.date_hour BETWEEN '2009-01-01 00:00:00' AND '2009-06-01 12:00:00';
Run Code Online (Sandbox Code Playgroud)
许多人似乎忽略的一点是,DBMS 通常(或只能)在查询中的每个表引用只使用一个索引,如果它可以并且确实使用多个索引,那么使用组合索引可能会更快索引(如果存在)。
例如,如果在大表中搜索行,WHERE AnIntegerColumn = 42 AND AnOtherInt = 69
那么到这些行的最快路径是 AnIntegerColumn 和 AnOtherInt 两列上的索引。如果每个单独的索引但没有组合索引,则数据库将搜索一个或另一个索引并使用第二个子句单独过滤结果,或者扫描两者并在之后将结果结合起来。
另一个可以使用复合索引改进的常见简单操作是WHERE SomeColumn = <SomeValue> ORDER BY SomeOtherColumn
- 如果 SomeColumn 和 SomeOtherColumn 上有索引(以正确的顺序),则在某些情况下可以同时执行过滤和排序操作。
添加太多索引当然可能是一个糟糕的优化,因为用于存储索引的额外空间(以及在您的数据库看到许多写操作时维护它们的 IO 负载)可能比稍微不太理想的读取查询更糟糕,所以不要过度。
归档时间: |
|
查看次数: |
4598 次 |
最近记录: |