数据库中聚集索引、非聚集索引、填充因子的概念？

说白了，索引就两种，聚集和非聚集，但选哪种、怎么用得看情况。

先说最重要的，聚集索引就是直接决定了数据在硬盘上的物理顺序。
去年我们跑那个电商大表，用户ID是唯一键，直接聚簇索引后，分分钟把按用户查订单的速度从1 s拉到0.1 s。
它只能有一个，所以得想明白哪个字段最常被查，比如订单表的订单时间，按天跑报表就建这个。
但别傻乎乎把所有表都按主键聚簇，想想去年调优时，有个表主键是自增ID，结果按客户名查超慢——因为物理顺序是按ID升序，客户名全在末尾，直接拖垮查询。
等等，还有个事，SQL Server建聚簇索引默认升序，搞个降序的得额外加个参数，但有时候降序确实能加速特定查询。

另外一点，非聚集索引就像一张地图，索引页里存着键值和指向真实数据的指针。
去年有个项目，表大概3 000万行，查某个城市用户的订单时，直接扫全表得跑1 分钟，加个非聚集索引后秒级出结果。
它可以在一个表搞到2 4 9 个，但别瞎加，有个表加了5 个非聚集索引后CPU飙到8 0%，因为每次查询都得多扫一轮索引。
填充因子这玩意儿也挺有意思，就是控制索引页填满多少。
默认0，页满了就拆分，但拆分要时间啊。
有个金融系统表，数据量不大但超频繁更新，我们调到7 0%填充因子，结果写操作速度明显快了，因为拆分次数少了。
但这个点很多人没注意，填充因子只在建或重建索引时管用，改完索引页不会自动维护那个水平，这点得记牢。

说实话挺坑的，很多人以为非聚集索引就是比聚簇索引慢，其实看场景。
精确匹配键值时它确实快，但范围查询或者索引覆盖（查询条件刚好被索引覆盖了）聚簇索引可能反超。
我觉得值得试试用SQL Profiler抓下真实查询，再根据结果调整索引策略。

sql创建索引例子

哈，你提到的这些SQL索引类型，我以前在实际工作中确实用过。
来，咱们就具体聊聊。

上周有个客人问我，怎么为员工表里某个字段创建个单列索引，比如员工的姓名。
这种情况，我们通常会用单列索引，这样查名字的时候就能快多了。
SQL语句就是这样的：
sql CREATE INDEX idx_employee_name ON employees(name);
然后，还有个情况，比如我们要根据部门和年龄来查询员工信息，这时候就可以用复合索引。
注意，复合索引的创建顺序很重要，因为它会按照从左到右的顺序来匹配。
所以，SQL语句会是：
sql CREATE INDEX idx_employee_dept_age ON employees(department_id, age);
说到唯一索引，这可是为了保证数据的唯一性。
比如，我们得确保每个员工的电子邮件地址都是独一无二的。
创建唯一索引的SQL语句是这样的：
sql CREATE UNIQUE INDEX idx_email ON employees(email);
全文索引嘛，这在处理文章内容搜索的时候特别有用。
比如，我们有一个文章内容的表articles，就可以这样创建全文索引：
sql CREATE FULLTEXT INDEX idx_article_content ON articles(content);
至于非聚集索引，这在SQL Server里用得比较多。
比如，我们要为TEST表的TNAME字段创建一个非聚集索引，SQL语句就是：
sql CREATE NONCLUSTERED INDEX IX_TEST_TNAME ON TEST(TNAME);
最后，提一下，我们还可以为视图创建索引，这样能提高查询性能。
但要注意，为视图创建的第一个索引必须是唯一聚集索引，之后才能创建更多非聚集索引。

总之，创建索引要根据实际情况来，这样才能达到最佳的性能优化效果。
反正你看着办，这些索引类型都是挺有用的。
我还在想这个问题，怎么在不同的场景下选择最合适的索引类型。

sql索引分为几类？

聚集索引确定数据物理顺序。
数据按键值排序存硬盘。

非聚集索引独立存放索引键。
数据页随机找物理位置。

例：InnoDB表主键用聚集索引。
主键ID从小到大连续存。

非聚集索引像电话本。
索引页存键值，指向数据页。

查询主键直接找物理位置快。
查询非聚集索引要额外找数据页。

我也还在验证不同引擎差异。
不确定但经验是这样。
你自己掂量。