SQL如何创建索引_SQL索引创建的步骤与作用

SQL创建索引，就是CREATE INDEX语句。
是的，它是 CREATE INDEX index_name ON table_name(column1 , column2 ,...)。
这个东西可以快速查数据，但是你要想想维护起来有多么困难。

我以前也遇到过这种情况，比如2 02 2 年的时候，我在某公司做一个项目，数据库很慢，查了半天数据。
我想知道是否应该添加索引。
然后我在用户表的电子邮件字段中添加了一个。
该语句是 CREATE INDEX idx_users_email ON users(email)。
添加之后，嘿嘿，居然快了很多。

索引，有几种类型。
B-Tree索引是最常见的，支持相等查询、范围查询和排序。
我的用户（电子邮件）是一个 B 树索引。
哈希索引，这个东西只支持等价查询，速度快，但是容易产生冲突。
全文索引，用于全文检索，可以匹配关键词。
空间索引，处理地理空间数据。
这些应该根据情况来选择。

索引列的选择取决于常用的列。
例如，经常出现在 WHERE 子句中的列，例如 status='active'。
连接字段是连接多个表时的关联列，如JOINordersONusers.id=orders.user_id。
排序字段是 ORDER BY 中的列，如 create_time DESC。
对于具有许多重复值的列（例如性别），不要创建索引，因为这是不必要的。

至于维护成本，索引占用磁盘空间。
当插入、更新或删除数据时，必须同时更新索引，速度会比较慢。
因此，对于读多写少的表，比如日志表，可以创建更多的索引。
不要创建写入次数多于读取次数的表，例如实时交易。

如何知道索引管是否工作？使用解释命令。
例如 EXPLAIN SELECT FROM users WHERE email='test@example.com';。
查看类型栏。
如果它是索引、范围或引用，则表示使用了索引。
如果是一切，那么就没有索引。
键列将显示实际使用的索引名称。

创建用户表的邮件索引后，我使用 EXPLAIN 来查看。
结果，键列显示 idx_users_email 并且我知道它的构造正确。

另外，不要过度索引。
每个索引都会增加写入开销。
必须定期维护并删除不必要的索引。
复合索引的顺序非常重要。
高频查询条件放在左侧。
例如，(user_id, create_time) 比 (create_time, user_id) 更好。

简而言之，索引可以提高查询性能，但也需要权衡。
大家想一想，这是真的吗？

SQL Server-索引的创建和删除

说实话，刚接手这个项目的时候，我对SQL Server索引是很困惑的。
后来我摸着石头慢慢过河，也有了一些经验。
创建和删除列的方法已经很清楚了，但我想补充一些我自己的理解和我遇到的陷阱。

在创建聚集索引时，自动创建部分确实很轻松。
我之前有一个旧项目。
数据库迁移的时候，表添加了PRIMARY KEY约束，我发现SQL Server自动建立了聚集索引。
当时没多想，后来让我按照某个字段对表和数据库进行分区，我就糊涂了——聚集索引不能改！只能先备份数据，删除索引，恢复表，添加约束。
这个教训太深刻了。
现在，当我为客户建表时，我会被提醒“一旦建立了聚集索引，就更难更改它了”。

手动构建聚集索引时，有一个细节需要注意。
例如，在您给出的 CREATE CLUSTERED INDEX IND_TNO ON T(TNO DESC) 示例中，我遇到了一次排序问题。
有一个订单表，是按照订单时间分组排序的，但是某个报表必须按照金额降序显示。
事实证明，数据的物理顺序与索引顺序不匹配，搜索性能下降。
后来我用非聚集索引+覆盖查询的方式解决了这个问题。
因此，如果过多使用降序聚集索引，就需要考虑数据插入的顺序是否会被打乱。

关于非聚集索引，我有一个案例特别新鲜。
之前是电商桌。
主键是自增ID，每个字段都添加了非聚集索引。
因此，在高峰期插入数据时，索引维护会消耗大量CPU，表插入延迟会成倍增加。
最后我们改变了策略：主表只保留ID和创建时间两个索引，关联表使用外键+非聚集索引。
数据量从5 00万条增长到5 000万条，查询速度提升5 0%。
说白了，索引越多越好。
这取决于实际场景。

删除索引没有太大问题。
但有一个小技巧要告诉大家。
有一个表的索引太多，想删除，又怕误删。
您可以使用此命令 sp_rename 'tablename._indexname', 'temporaryname' 更改索引名称，然后将其删除。
例如，在删除 IND_TNO 之前，先 sp_rename 'T._IND_TNO', 'TEMP_INDEX'，这样它在索引管理器中看起来会更清晰。

最后说一点小知识。
有一个项目使用SQL Server 2 01 6 ，表数据量为1 亿，有一个查询运行速度极其缓慢。
检查了半天，发现统计列索引没有打开。
进行更改后，我意识到统计列索引对于优化某些聚合查询具有惊人的效果。
我没有操作过这个领域，但是客户的案例提醒我不要把统计列索引当作摆设。

让我们索引这个东西。
归根结底，还是要看业务。
有一个客户是做物流的，我帮忙设计了表结构。
他坚持给运单表的每个字段都加上索引，因为客服可能随时想查。
结果系统运行一年后，我们发现9 0%的客户服务请求都是基于“当前用户能看到的运单”，而指标却并非如此作为一种很好的分区策略。
所以你说索引设计比查资料还繁琐，你得懂业务。