我要提问
- 关于
数据库索引
的搜索结果
回答
详细解答可以参考官方帮助文档问题列表日志服务如何存储、管理用户的日志？删除日志库，日志数据是否丢失？日志服务日志保存多长时间？可否修改这个保存时限？希望把日志最终存储到OSS，怎样节省在日志服务上的花费？
1. 日志服务如何存储、管理用户的日志？
日志库（Logstore）是日志服务中的日志存储和查询的基本单元，通常用于存储一类日志数据。目前，支持在控制台或者通过API完成对日志库的增删改查操作。日志库创建完成后，用户通过API或SDK向指定日志库写入日志数据。如果用户希望收集阿里云ECS服务器的数据，日志服务提供的Logtail日志收集服务同样非常方便地收集到日志数据。
2. 删除日志库，日志数据是否丢失？
删除日志库会导致日志数据丢失，请谨慎操作。
3. 日志服务日志保存多长时间？可否修改这个保存时限？
日志服务有三项功能都与日志保存时间有关，分别如下：
LogHub（日志中枢）/LogSearch（日志索引与查询）：根据需求自行设置。LogShipper（日志投递）：日志投递至OSS、MaxCompute后，生命周期在以上产品中设置。
4. 希望把日志最终存储到OSS，怎样节省在日志服务上的花费？
日志服务的索引分析提供强大功能的同时会产生一定费用，如果您的需求是将日志保存到OSS上，且没有自定义日志查询、分析等需求，可以通过以下方式削减账单费用。
注意事项
索引默认关闭，如您并未开启索引和分析功能，请修改Logstore数据保存时间减少数据存储费用。
修改关闭索引分析功能，会使得日志关键词查询、日志统计分析、Dashboard、告警等功能不可用，请谨慎操作。
节省费用方式
修改Logstore数据保存时间。
参考操作Logstore，修改Logstore数据保存时间为1天。日志服务收取一定的Logstore数据存储费用，您可以选择缩减存储时间以降低消费。
关闭索引功能。
开启OSS投递功能，将Logstore数据准实时投递到OSS保存。
进入Logstore列表页，单击查询。
删除索引以关闭索引分析功能。
执行以上步骤后，日志服务仅收取您很低的使用LogHub功能费用，了解更多请参考计费方式。
回答
简单的说：查询的时候生效。索引（indexes）就好像书籍的目录／或者字典里的字母表和偏旁部首表（这也是 index 的本意），它在你需要从书或字典里查找内容的时候发挥作用。比如说你有一本关于数据库的书（相当于表），你想要查询其中关于索引的章节（查询条件），你就可以在目录里（相当于索引）找到索引标题，然后看到对应的页数为235（记录行数），这样你很快就找到它了。如果你没有索引，那就只能一页一页的翻直到找到索引这一章为止，这就叫做全表扫描——当然是不好的。但是索引也不是只要有了就一定好的。还是上面的例子，假设这一次你要找的是数据库（想想看，一本关于数据库的书，里面会有多少内容是包含数据库三个字的），那么索引几乎帮不上你什么忙（结果太多了），这和你做一次全表扫描没啥差别。再比方说你这本书一共就10页，那么索引也没啥用处（索引本身还得占个一两页）。索引本身得有意义，标记重要的，极少重复的信息。对于一本书来说，你把每一个字都做索引就是毫无意义的事情。综上所述你大概就知道在什么条件下你才可以直观的感受到索引带来的变化了吧？
回答
差异性 KEY或INDEX是指普通的非唯一索引。允许使用索引的非唯一值，因此索引的所有列中可能包含具有相同值的行。这些索引不会对您的数据施加任何限制，因此它们仅用于访问-快速访问某些记录范围而无需扫描所有记录。
UNIQUE引用一个索引，其中索引的所有行都必须是唯一的。也就是说，对于该索引中的所有列，同一行可能不具有与另一行相同的非NULL值。除了用于快速达到某些记录范围外，UNIQUE索引还可以用于对数据施加约束，因为数据库系统不允许在插入或更新数据时打破唯一值规则。
您的数据库系统可能允许将UNIQUE索引应用于允许NULL值的列，在这种情况下，如果两行都包含NULL值，则允许两行相同（此处的理由是NULL被视为不等于其自身）。但是，根据您的应用程序，您可能会发现这是不希望的：如果希望防止这种情况，则应在相关列中禁止使用NULL值。
PRIMARY的行为与UNIQUE索引完全相同，不同之处在于它始终被命名为“ PRIMARY”，并且表上可能只有一个（并且应该总是一个；尽管某些数据库系统不强制执行此操作）。PRIMARY索引旨在作为唯一标识表中任何行的主要手段，因此与UNIQUE不同，它不应在任何允许NULL值的列上使用。您的PRIMARY索引应位于足以唯一标识一行的最少列数上。通常，这只是一列，其中包含一个唯一的自动递增的数字，但是，如果还有其他任何东西可以唯一地标识一行，例如国家列表中的“国家/地区代码”，则可以改用它。
某些数据库系统（例如MySQL的InnoDB）会将表的记录存储在磁盘上，顺序是它们在PRIMARY索引中出现的顺序。
FULLTEXT索引与上述所有索引均不同，并且它们的行为在数据库系统之间也存在很大差异。FULLTEXT索引仅对使用MATCH（）/ AGAINST（）子句进行的全文搜索有用，与上述三个不同（通常在内部使用b树（允许选择，排序或从最左列开始的范围）实现）哈希表（允许从最左边的列开始选择）。
在其他索引类型是通用索引的情况下，FULLTEXT索引是专用的，因为它的作用范围很窄：它仅用于“全文搜索”功能。
相似之处 所有这些索引中可能都包含不止一列。
除FULLTEXT外，列顺序很重要：要使索引在查询中有用，查询必须使用从左开始的索引中的列-它不能仅使用索引的第二，第三或第四部分。索引，除非它也使用索引中的前几列来匹配静态值。（为使FULLTEXT索引对查询有用，该查询必须使用索引的所有列。）来源：stack overflow
回答
回 2楼(zc_0101) 的帖子
您好，
您的问题非常好，SQL SERVER提供了很多关于I/O压力的性能计数器，请选择性能计算器PhysicalDisk（LogicalDisk），根据我们的经验，如下指标的阈值可以帮助你判断IO是否存在压力：
1. % Disk Time ：这个是磁盘时间百分比，这个平均值应该在85%以下
2. Current Disk Queue Length：未完成磁盘请求数量，这个每个磁盘平均值应该小于2.
3. Avg. Disk Queue Length：磁盘请求队列的平均长度，这个每个磁盘平均值也应该小于2
4. Disk Transfers/sec：每次磁盘传输数量，这个每个磁盘的最大值应该小于100
5. Disk Bytes/sec：每次磁盘传入字节数，这个在普通的磁盘上应该在10M左右
6. Avg. Disk Sec/Read：从磁盘读取的平均时间，这个平均值应该小于10ms(毫秒)
7. Avg. Disk Sec/Write：磁盘写入的平均时间，这个平均值也应该小于10ms(毫秒)
以上，请根据自己的磁盘系统判断，比如传统的机械臂磁盘和SSD有所不同。
一般磁盘的优化方向是：
1. 硬件优化：比如使用更合理的RAID阵列，使用更快的磁盘驱动器，添加更多的内存
2. 数据库设置优化：比如创建多个文件和文件组，表的INDEX和数据放到不同的DISK上，将数据库的日志放到单独的物理驱动器，使用分区表
3. 数据库应用优化：包括应用程序的设计，SQL语句的调整，表的设计的合理性，INDEX创建的合理性，涉及的范围很广
希望对您有所帮助，谢谢！
-------------------------
回 3楼(鹰舞) 的帖子
您好，
根据您的描述，由于查询产生了副本REDO LOG延迟，出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁：
架构锁分成两类：
1. SCH-M：架构更改锁，主要发生在数据库SCHEMA的修改上，从你的描述看，没有更改SCHEMA，那么可以排除这个因素
2. SCH-S：架构稳定锁，主要发生在数据库的查询编译等活动
根据你的情况，应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息，未参数化的SQL语句等等
对于INDEX和SQL语句方面应，我想应该不会有太多问题。
我们重点关注一下统计信息：SQL SERVER 2012 AG副本的统计信息维护有两种：
1. 主体下发到副本
2. 临时统计信息存储在TEMPDB
对于主体下发的，我们可以设置统计信息的更新行为，自动更新时，可以设置为异步的（自动更新统计信息必须首先打开）：
USE [master]
GO
ALTER DATABASE [Test_01]
SET AUTO_UPDATE_STATISTICS_ASYNC ON
WITH NO_WAIT
GO
这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。
对于临时统计信息存储在TEMPDB里面也是很重要的，再加上ALWAYSON的副本数据库默认是快照隔离，优化TEMPDB也是必要的，关于优化TEPDB这个我想大部分都知道，这里只是提醒一下。
除了从统计信息本身来解决，在查询过程中，可以降低查询的时间，以尽量减少LOCK的时间和范围，这需要优化你的SQL语句或者应用程序。
以上，希望对您有所帮助。谢谢！
-------------------------
回 4楼(leamonjxl) 的帖子
这是一个关于死锁的问题，为了能够提供帮助一些。请根据下列建议进行：
1. 跟踪死锁
2. 分析死锁链和原因
3. 一些解决办法
关于跟踪死锁，我们首先需要打开1222标记，例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息：
如果发生了死锁，需要分析死锁发生的根源在哪里？我们不是很清楚你的具体发生死锁的形态是怎么样的。
关于死锁的实例也多，这里不再举例。
这里只是提出一些可以解决的思路：
1. 减少锁的争用
2. 减少资源的访问数
3. 按照相同的时间顺序访问资源
减少锁的争用，可以从几个方面入手
1. 使用锁提示，比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许，大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。
2. 调整隔离级别，使用MVCC，我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别，这样的话可以尽量读写不阻塞，只不过MVCC的ROW VERSION保存到TEMPDB下面，需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED，这些就不必了。
减少资源的访问数，可以从如下几个方面入手：
1. 使用聚集索引，非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此，如果对非聚集INDEX 操作的话，会产生两个锁，一个是基本表，一个是非聚集INDEX。而聚集INDEX就不一样，聚集INDEX的叶子页面和表的数据页面相同，他只需要一个LOCK。
2. 查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX，就不需要访问基本表。如果没有全覆盖，还会通过RID或者CLUSTER INDEX访问基本表，这样产生的LOCK可能会与其他SESSION争用。
按照相同的时间顺序访问资源：
确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问，第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK，但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。
-------------------------
回 4楼(leamonjxl) 的帖子
两种方式看你的业务怎么应用。这里不仅是分表的问题，还可能存在分库，分服务器的问题。取决与你的架构方案。
物理分表+视图，这是一种典型的冷热数据分离的方案，大致的做法如下：
1. 保留最近3个月的数据为当前表，也即就是我们说的热数据
2. 将其他数据按照某种规则分表，比如按照年或者季度或者月，这部分是相对冷的数据
分表后，涉及到几个问题：
第一问题是，转移数据的过程，一般是晚上业务比较闲来转移，转移按照一定的规则来做，始终保持3个月，这个定时任务本身也很消耗时间
再者，关于查询部分，我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧，主库我觉得压力不会太大，主要是插入或者更新，只读需要做视图来包含全部的数据，但通过UNION ALL所有分表的数据，最后可能还是非常大，在某些情况下，性能不一定好。这个是不是业务上可以解决。比如，对于1年前的历史数据，放在单独的只读上，相对热的数据放在一起，这样压力也会减少。
分区表的话，因为涉及到10亿数据，要有好的分区方案，相对比较简单一点。但对于10亿的大表，始终是个棘手的问题，无论分多少个分区，单个服务器的资源也是有限的。可扩展性方面也存在问题，比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。
现在很多企业都在做分库分表，这些的要解决一些高并发，数据量大的问题。不知是否考虑过类似于中间件的方案，比如阿里巴巴的TDDL类似的方案，如果你有兴趣，可以查询相关资料。
-------------------------
回 9楼(jiangnii) 的帖子
阿里云数据库不仅提供一个数据库，还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署，还提供了数据库高可用性架构，备份服务，性能诊断服务，监控服务，专家服务等等，保证用户放心、方便、省心地使用数据库，就像水电一样。以前的运维繁琐的事，全部由阿里云接管，用户只需要关注数据库的使用和具体的业务就好。
关于优化和在云数据库上处理大数据量或复杂的数据操作方面，在云数据库上是一样的，没有什么特别的地方，不过我们的云数据库是使用SSD磁盘，这个比普通的磁盘要快很多，IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务，比如索引诊断，连接诊断，容量分析，空间诊断等等，这些工作可能是专业的DBA才能完成的，以后我们会提供自动化的服务来为客户创造价值，希望能帮助到客户。
谢谢！
-------------------------
回 12楼(daniellin17) 的帖子
这个问题我不知道是否是两个问题，一个是并行度，另一个是并发，我更多理解是吞吐量，单就并行度而言。
提高并行度需要考虑的因素有：
1. 可用于SQL SERVER的CPU数量
2. SQL SERVER的版本（32位/64位）
3. 可用内存
4. 执行的查询类型
5. 给定的流中处理的行数
6. 活动的并发连接数量
7. sys.configurations参数：affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism
以DOP的参数控制并行度为例，设置如下：
SELECT *
FROM sys.configurations WITH (NOLOCK)
WHERE name = 'max degree of parallelism'
EXEC sp_configure 'max degree of parallelism',2
RECONFIGURE WITH OVERRIDE
经过测试，DOP设置为2是一个比较适中的状态，特别是OLTP应用。如果设置高了，会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是：CXPACKET
你可以用下列语句去测试：
DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR)
SELECT *
FROM sys.dm_os_wait_stats WITH (NOLOCK)
ORDER BY 2 DESC ,3 DESC
如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话，大多根据业务量来预估，然后考虑以下：
1. RAID的划分，RAID1适合存放事务日志文件(顺序写)，RAID10/RAID5适合做数据盘,RAID10是条带化并镜像，RAID5条带化并奇偶校验
2. 数据库设置，比如并行度，连接数，BUFFER POOL
3. 数据库文件和日志文件的存放规则，数据库文件的多文件设置规则
4. TEMPDB的优化原则，这个很重要的
5. 表的设计方面根据业务类型而定
6. CLUSTERED INDEX和NONCLUSTERED INDEX的设计
7. 阻塞分析
8. 锁和死锁分析
9. 执行计划缓冲分析
10. 存储过程重编译
11. 碎片分析
12. 查询性能分析,这个有很多可以优化的方式，比如OR/UNION/类型转换/列上使用函数等等
我这里列举一个高并发的场景：
比如，我们的订单，比如搞活动的时候，订单刷刷刷地增长，单个实例可能每秒达到很高很高，我们分析到最后最常见的问题是HOT PAGE问题，其等待类型是PAGE LATCH竞争。这个过程可以这么来处理，简单列几点，可以参考很多涉及高并发的案例：
1. 数据库文件和日志文件分开，存放在不同的物理驱动器磁盘上
2. 数据库文件需要与CPU个数形成一定的比例
3. 表设计可以使用HASH来作为表分区
4. 表可以设置无序的KEY/INDEX，比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX
5. 我们不能将自增列设计为聚集INDEX
这个场景只是针对高并发的插入。对于查询而言，是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。
-------------------------
回 13楼(zuijh) 的帖子
ECS上现在有两种磁盘，一种是传统的机械臂磁盘，另一种是SSD，请先诊断你的IO是否出现了问题，本帖中有提到如何判断磁盘出现问题的相关话题，请参考。如果确定IO出现问题，可以尝试使用ECS LOCAL SSD。当然，我们欢迎你使用云数据库的产品，云数据库提供了很多有用的功能，比如高可用性，灵活的备份方案，灵活的弹性方案，实用的监控报警等等。
-------------------------
回 17楼(豪杰本疯子) 的帖子
我们单个主机或者单个实例的资源总是有限的，因为涉及到很大的数据量，对于存储而言是个瓶颈，我曾使用过SAN和SAS存储，SAN存储的优势确实可以解决数据的灵活扩展，但是SAN也分IPSAN和FIBER SAN，如果IPSAN的话，性能会差一些。即使是FIBER SAN，也不是很好解决性能问题，这不是它的优势，同时，我们所有DB SERVER都连接到SAN上，如果SAN有问题，问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大，是造成性能问题的直接原因，因为我们不管怎么优化，一旦数据量太大，优化的能力总是有限的，所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。
所以现在很多企业在向分布式系统发展，对于数据库而言，其实有很多形式。我们最常见的是读写分离，比如SQL SERVER而言，我们可以通过复制来完成读写分离，SQL SERVER 2012及以后的版本，我们可以使用ALWAYSON来实现读写分离，但这只能解决性能问题，那空间问题怎么解决。我们就涉及到分库分表，这个分库分表跟应用结合得紧密，现在很多公司通过中间件来实现，比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分，那么DB也可以由此拆分开来。举个简单例子，我们一个典型的电子商务系统，有订单，有促销，有仓库，有配送，有财务，有秒杀，有商品等等，很多公司在初期，都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后，就会出现性能和硬件资源问题，这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。
-------------------------
回 21楼(dt) 的帖子
问：
求大数据量下mysql存储，优化方案
分区好还是分表好，分的过程中需要考虑事项
mysql高并发读写的一些解决办法
答：
分区：对于应用来说比较简单,改造较少
分表: 应用需较多改造，优点是数据量太大的情况下，分表可以拆分到多个实例上，而分区不可以。
高并发优化,有两个建议:
1. 优化事务逻辑
2. 解决mysql高并发热点,这个可以看看阿里的一个热点补丁:
http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f
-------------------------
回 23楼(aelven) 的帖子
对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势，比如磁盘是性能超好的SSD，自动转移的高可用性，没有任何单点，自动灵活的备份方案，实用的监控报警，性能监控服务等等，省去DBA很多基础性工作。
你第二个问题，看起来是一个高并发的场景，这种高并发的场景容易出现大量的LOCK甚至死锁，我不是很清楚你的业务，但可以建议一下，首先可以考虑快照隔离级别，实现行多版本控制，让读写不要阻塞。至于写写过程，需要加锁的粒度降低最低，同时这种高并发也容易出现死锁，关于死锁的分析，本帖有提到，请关注。
第三个问题，你用ECS搭建自己的应用也是可以的，RDS数据库提供了很多功能，上面已经讲到了。安全问题一直是我们最看重的问题，肯定有超好的防护的。
-------------------------
回 26楼(板砖大叔) 的帖子
我曾经整理的关于索引的设计与规范，可以供你参考：
-----------------------------------------------------------------------
索引设计与规范
1.1 使用索引
SQL SERVER没有索引也可以检索数据，只不过检索数据时扫描这个表而异。存储数据的目的，绝大多数都是为了再次使用，而一般数据检索都是带条件的检索，数据查询在数据库操作中会占用较大的比例，提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构，最小优化了定位所需要的键值的访问页面量，包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起，它决定表中数据存储的物理顺序，其叶子节点为数据行。
1.2 聚集索引
1.2.1 关于聚集索引
没聚集索引的表叫堆。堆是一种没有加工的数据，以行标示符作为指向数据存储位置的指针，数据没有顺序。聚集索引的叶子页面和表的数据页面相同，因此表行物理上按照聚集索引列排序，表数据的物理顺序只有一种，所以一个表只有一个聚集索引。
1.2.2 与非聚集索引关系
非聚集索引的一个索引行包含指向表对应行的指针，这个指针称为行定位器，行定位器的值取决于数据页保存为堆还是被聚集。若是堆，行定位器指向的堆中数据行的行号指针，若是聚集索引表，行定位器是聚集索引键值。
1.2.3 设计聚集索引注意事项
首先创建聚集索引
聚集索引上的列需要足够短
一步重建索引，不要使用先DROP再CREATE，可使用DROP_EXISTING
检索一定范围和预先排序数据时使用，因为聚集索引的叶子与数据页面相同，索引顺序也是数据物理顺序，读取数据时，磁头是按照顺序读取，而不是随机定位读取数据。
在频繁更新的列上不要设计聚集索引，他将导致所有的非聚集所有的更新，阻塞非聚集索引的查询
不要使用太长的关键字，因为非聚集索引实际包含了聚集索引值
不要在太多并发度高的顺序插入，这将导致页面分割，设置合理的填充因子是个不错的选择
1.3 非聚集索引
1.3.1 关于非聚集索引
非聚集索引不影响表页面中数据的顺序，其叶子页面和表的数据页面时分离的，需要一个行定位器来导航数据，在将聚集索引时已经有说明，非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型，比如覆盖索引，过滤索引等。
1.3.2 设计非聚集索引
频繁更新的列，不适合做聚集索引，但可以做非聚集索引
宽关键字，例如很宽的一列或者一组列，不适合做聚集索引的列可作非聚集索引列
检索大量的行不宜做非聚集索引，但是可以使用覆盖索引来消除这种影响
1.3.3 优化书签查找
书签会访问索引之外的数据，在堆表，书签查找会根据RID号去访问数据，若是聚集索引表，一般根据聚集索引去查找。在查询数据时，要分两个部分来完成，增加了读取数据的开销，增加了CPU的压力。在大表中，索引页面和数据页面一般不会临近，若数据只存在磁盘，产生直接随机从磁盘读取，这导致更多的消耗。因此，根据实际需要优化书签查找。解决书签查找有如下方法：
使用聚集索引避免书签查找
使用覆盖索引避免书签查找
使用索引连接避免数据查找
1.4 聚集与非聚集之比较
1.4.1 检索的数据行
一般地，检索数据量大的一般使用聚集索引，因为聚集索引的叶子页面与数据页面在相同。相反，检索少量的数据可能非聚集索引更有利，但注意书签查找消耗资源的力度，不过可考虑覆盖索引解决这个问题。
1.4.2 数据是否排序
如果数据需要预先排序，需要使用聚集索引，若不需要预先排序就那就选择聚集索引。
1.4.3 索引键的宽度
索引键如果太宽，不仅会影响数据查询性能，还影响非聚集索引，因此，若索引键比较小，可以作为聚集索引，如果索引键够大，考虑非聚集索引，如果很大的话，可以用INCLUDE创建覆盖索引。
1.4.4 列更新的频度
列更新频率高的话，应该避免考虑所用非聚集索引，否则可考虑聚集索引。
1.4.5 书签查找开销
如果书签查找开销较大，应该考虑聚集索引，否则可使用非聚集索引，更佳是使用覆盖索引，不过得根据具体的查询语句而看。
1.5 覆盖索引
覆盖索引可显著减少查询的逻辑读次数，使用INCLUDE语句添加列的方式更容易实现，他不仅减小索引中索引列的数据，还可以减少索引键的大小，原因是包含列只保存在索引的叶子级别上，而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生，与聚集索引类似，因为聚集索引值发生一次锁，非覆盖索引可能发生两次，一次锁数据，一次锁索引，以确保数据的一致性。覆盖索引相当于数据的一个拷贝，与数据页面隔离，因此也只发生一次锁。
1.6 索引交叉
如果一个表有多个索引，那么可以拥有多个索引来执行一个查询，根据每个索引检索小的结果集，然后就将子结果集做一个交叉，得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。
1.7 索引连接
几乎是跟索引交叉类似，是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询，SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。
1.8 过滤索引
用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效，创建索引时，可以像写T-SQL语句一样加个WHERE条件，以排除某部分数据而检索。
1.9 索引视图
索引视图在OLAP系统上可能有胜算，在OLTP会产生过大的开销和不可操作性，比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构，索引视图要求企业版，这些限制导致不可操作性。
1.10 索引设计建议
1.10.1 检查WHERE字句和连接条件列
检查WHERE条件列的可选择性和数据密度，根据条件创建索引。一般地，连接条件上应当考虑创建索引，这个涉及到连接技术，暂时不说明。
1.10.2 使用窄的索引
窄的索引有可减少IO开销，读取更少量的数据页。并且缓存更少的索引页面，减少内存中索引页面的逻辑读取大小。当然，磁盘空间也会相应地减少。
1.10.3 检查列的唯一性
数据分布比较集中的列，种类比较少的列上创建索引的有效性比较差，如果性别只有男女之分，最多还有个UNKNOWN，单独在上面创建索引可能效果不好，但是他们可以为覆盖索引做出贡献。
1.10.4 检查列的数据类型
索引的数据类型是很重要的，在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型，在数据长度较小的类型上创建又比在长度较长的类型上更有效。
1.10.5 考虑列的顺序
对于包含多个列的索引，列顺序很重要。索引键值在索引上的第一上排序，然后在前一列的每个值的下一列做子排序，符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性，列宽度，列的数据类型来做权衡。
1.10.6 考虑索引的类型
使用索引类型前面已经有较多的介绍，怎么选择已经给出。不再累述。
-------------------------
回 27楼(板砖大叔) 的帖子
这两种都可以吧。看个人的喜好，不过微软现在的统一风格是下划线，比如表sys.all_columns/sys.tables，然后你再看他的列全是下划线连接，name /object_id /principal_id /schema_id /parent_object_id /type /type_desc /create_date /modify_date
我个人的喜好也是喜欢下划线。
回答
基本上，表上的索引的作用类似于书中的索引（这就是名称的来源）：
假设您有一本关于数据库的书，并且想要查找有关存储的信息。没有索引（假设没有其他帮助，例如目录），则必须逐个浏览页面，直到找到主题（即full table scan）为止。另一方面，索引包含一个关键字列表，因此您可以查阅该索引，并storage在第113-120,231和354页中看到该索引。然后，您可以直接跳至这些页面，而无需进行搜索（即使用索引，速度更快）。
当然，索引的有用程度取决于很多事情-使用上面的比喻的几个例子：
如果您有一本关于数据库的书并为“数据库”一词建立了索引，您会发现它在第1-59,61-290页和第292至400页中提到。在这种情况下，索引并没有太大帮助，它可能更快地一页一页地浏览页面（在数据库中，这是“选择性差”）。 对于一本10页的书，建立索引是没有意义的，因为您可能最终得到一本10页的书，并以5页的索引为前缀，这很愚蠢-只需扫描10页并完成即可。 索引也需要有用-通常没有指向索引的位置，例如每页字母“ L”的频率。来源：stack overflow
回答
首先sphinx独立于项目，你可以理解成一个数据库。所有需要搜索的数据都存储在sphinx中，比如文章、商品、用户等。使用时要先把数据存储到sphinx中。可以使用sphinx自己的indexer来生成索引，让sphinx把所有的数据从MySQL中获取到然后存储到自己的索引中。然后就可以调用sphinx的api从sphinx中检索数据。一般从sphinx检索出数据的ID然后根据ID再去数据库中获取最新的数据（以防数据不一致，比如商品的库存、最新价格等）类似的产品还有很多比如国外的Elasticsearch ( https://www.elastic.co/products/elasticsearch )国产的XunSearch ( http://www.xunsearch.com ) 据说Segmentfault使用的XunSearch与Sphinx不同的是，你需要自己写一个程序或脚本把数据同步到他们自己的索引数据库中。
回答
mysql的聚簇索引是指innodb引擎的特性，mysiam并没有，如果需要该索引，只要将索引指定为主键（primary key）就可以了。比如：create table blog_user( user_Name char(15) not null check(user_Name !=''), user_Password char(15) not null, user_emial varchar(20) not null unique, primary key(user_Name) )engine=innodb default charset=utf8 auto_increment=1;其中的 primary key(user_Name) 这个就是聚簇索引索引了；聚簇索引的叶节点就是数据节点，而非聚簇索引的叶节点仍然是索引节点，并保留一个链接指向对应数据块。聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。相比之下，聚簇索引适合排序，非聚簇索引（也叫二级索引）不适合用在排序的场合。因为聚簇索引本身已经是按照物理顺序放置的，排序很快。非聚簇索引则没有按序存放，需要额外消耗资源来排序。当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。另外，二级索引需要两次索引查找，而不是一次才能取到数据，因为存储引擎第一次需要通过二级索引找到索引的叶子节点，从而找到数据的主键，然后在聚簇索引中用主键再次查找索引，再找到数据。innodb索引分类：聚簇索引(clustered index) 1) 有主键时，根据主键创建聚簇索引 2) 没有主键时，会用一个唯一且不为空的索引列做为主键，成为此表的聚簇索引 3) 如果以上两个都不满足那innodb自己创建一个虚拟的聚集索引辅助索引(secondary index) 非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引 myisam索引：因为myisam的索引和数据是分开存储存储的，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索 索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因 innodb索引：innodb的数据和索引放在一起，当找到索引也就找到了数据 自适应哈希索引：innodb会监控表上的索引使用情况，如果观察到建立哈希索引可以带来速度的提升，那就建立哈希索引，自 适应哈希索引通过缓冲池的B+树构造而来， 因此建立的速度很快，不需要将整个表都建哈希索引，InnoDB 存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。自适应哈希索引不需要 存储磁盘的，当停库内容会丢失，数据库起来会自己创建，慢慢维护索引。 聚簇索引：MySQL InnoDB一定会建立聚簇索引，把实际数据行和相关的键值保存在一块，这也决定了一个表只能有一个聚簇索引，即MySQL不会一次把数据行保存在二个地方。 1) InnoDB通常根据主键值(primary key)进行聚簇 2) 如果没有创建主键，则会用一个唯一且不为空的索引列做为主键，成为此表的聚簇索引 3) 上面二个条件都不满足，InnoDB会自己创建一个虚拟的聚集索引 优点：聚簇索引的优点,就是提高数据访问性能。聚簇索引把索引和数据都保存到同一棵B+树数据结构中，并且同时将索引列与相关数据行保存在一起。这意味着，当你访问同一数据页不同行记录时，已经把页加载到了Buffer中，再次访问的时候，会在内存中完成访问，不必访问磁盘。不同于MyISAM引擎，它将索引和数据没有放在一块，放在不同的物理文件中，索引文件是缓存在key_buffer中，索引对应的是磁盘位置，不得不通过磁盘位置访问磁盘数据。 缺点：1) 维护索引很昂贵，特别是插入新行或者主键被更新导至要分页(page split)的时候。建议在大量插入新行后，选在负载较低的时间段，通过OPTIMIZE TABLE优化表，因为必须被移动的行数据可能造成碎片。使用独享表空间可以弱化碎片 2) 表因为使用UUId作为主键，使数据存储稀疏，这就会出现聚簇索引有可能有比全表扫面更慢，所以建议使用int的auto_increment作为主键 3) 如果主键比较大的话，那辅助索引将会变的更大，因为辅助索引的叶子存储的是主键值；过长的主键值，会导致非叶子节点占用占用更多的物理空间 辅助索引在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找。辅助索引叶子节点存储的不再是行的物理位置，而是主键值。通过辅助索引首先找到的是主键值，再通过主键值找到数据行的数据叶，再通过数据叶中的Page Directory找到数据行。复合索引由多列创建的索引称为符合索引，在符合索引中的前导列必须出现在where条件中，索引才会被使用ALTER TABLE test.users ADD INDEX idx_users_id_name (name(10) ASC, id ASC) ; 前缀索引当索引的字符串列很大时，创建的索引也就变得很大，为了减小索引体积，提高索引的扫描速度，就用索引的前部分字串索引，这样索引占用的空间就会大大减少，并且索引的选择性也不会降低很多。而且是对BLOB和TEXT列进行索引，或者非常长的VARCHAR列，就必须使用前缀索引，因为MySQL不允许索引它们的全部长度。使用：列的前缀的长度选择很重要，又要节约索引空间，又要保证前缀索引的选择性要和索引全长度选择性接近。 唯一索引唯一索引比较好理解，就是索引值必须唯一，这样的索引选择性是最好的 主键索引主键索引就是唯一索引，不过主键索引是在创建表时就创建了，唯一索引可以随时创建。说明主键和唯一索引区别 1) 主键是主键约束+唯一索引 2) 主键一定包含一个唯一索引，但唯一索引不是主键 3) 唯一索引列允许空值，但主键列不允许空值 4) 一个表只能有一个主键，但可以有多个唯一索引 索引扫描方式：紧凑索引扫描(dense index)：在最初，为了定位数据需要做权表扫描，为了提高扫描速度，把索引键值单独放在独立的数据的数据块里，并且每个键值都有个指向原数据块的指针，因为索引比较小，扫描索引的速度就比扫描全表快，这种需要扫描所有键值的方式就称为紧凑索引扫描 松散索引扫描(sparse index)：为了提高紧凑索引扫描效率，通过把索引排序和查找算法（B+trre），发现只需要和每个数据块的第一行键值匹配，就可以判断下一个数据块的位置或方向，因此有效数据就是每个数据块的第一行数据，如果把每个数据块的第一行数据创建索引，这样在这个新创建的索引上折半查找，数据定位速度将更快。这种索引扫描方式就称为松散索引扫描。 覆盖索引扫描(covering index)：包含所有满足查询需要的数据的索引称为覆盖索引，即利用索引返回select列表中的字段，而不必根据索引再次读取数据文件索引相关常用命令：1) 创建主键 CREATE TABLE pk_tab2 ( id int(11) NOT NULL AUTO_INCREMENT, a1 varchar(45) DEFAULT NULL, PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8; 2) 创建唯一索引create unique index indexname on tablename(columnname); alter table tablename add unique index indexname(columnname); 3) 创建单列一般索引create index indexname on tablename(columnname);alter table tablename add index indexname(columnname); 4) 创建单列前缀索引create index indexname on tablename(columnname(10)); //单列的前10个字符创建前缀索引alter table tablename add index indexname(columnname(10)); //单列的前10个字符创建前缀索引 5) 创建复合索引create index indexname on tablename(columnname1，columnname2); //多列的复合索引create index indexname on tablename(columnname1，columnname2(10)); //多列的包含前缀的复合索引alter table tablename add index indexname(columnname1，columnname2); //多列的复合索引alter table tablename add index indexname(columnname1，columnname(10)); //多列的包含前缀的复合索引 6) 删除索引drop index indexname on tablename;;alter table tablename drop index indexname; 7) 查看索引show index from tablename;show create table pk_tab2;作者：大树叶 来源：CSDN 原文：https://blog.csdn.net/bigtree_3721/article/details/51335479 版权声明：本文为博主原创文章，转载请附上博文链接！
回答
使用索引是数据库性能优化的必备技能之一。在MySQL数据库中，有四种索引：聚集索引(主键索引)、普通索引、唯一索引以及我们这里将要介绍的全文索引(FULLTEXT INDEX)。 全文索引(也称全文检索)是目前搜索引擎使用的一种关键技术。它能够利用「分词技术「等多种算法智能分析出文本文字中关键字词的频率及重要性，然后按照一定的算法规则智能地筛选出我们想要的搜索结果。在这里，我们就不追根究底其底层实现原理了，现在我们来看看在MySQL中如何创建并使用全文索引。 在MySQL中，创建全文索引相对比较简单。例如，我们有一个文章表(article)，其中有主键ID(id)、文章标题(title)、文章内容(content)三个字段。现在我们希望能够在title和content两个列上创建全文索引，article表及全文索引的创建SQL语句如下： --创建article表 CREATE TABLE article ( id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY, title VARCHAR(200), content TEXT, FULLTEXT (title, content) --在title和content列上创建全文索引 ); 上面就是在创建表的同时建立全文索引的SQL示例。此外，如果我们想要给已经存在的表的指定字段创建全文索引，同样以article表为例，我们可以使用如下SQL语句进行创建： --给现有的article表的title和content字段创建全文索引 --索引名称为fulltext_article ALTER TABLE article ADD FULLTEXT INDEX fulltext_article (title, content) 在MySQL中创建全文索引之后，现在就该了解如何使用了。众所周知，在数据库中进行模糊查询是使用LIKE关键字进行查询，例如： SELECT * FROM article WHERE content LIKE '%查询字符串%' 那么，我们使用全文索引也是这样用的吗？当然不是，我们必须使用特有的语法才能使用全文索引进行查询。例如，我们想要在article表的title和content列中全文检索指定的查询字符串，可以如下编写SQL语句： SELECT * FROM article WHERE MATCH(title, content) AGAINST('查询字符串') 强烈注意：MySQL自带的全文索引只能用于数据库引擎为MyISAM的数据表，如果是其他数据引擎，则全文索引不会生效。此外，MySQL自带的全文索引只能对英文进行全文检索，目前无法对中文进行全文检索。如果需要对包含中文在内的文本数据进行全文检索，我们需要采用Sphinx(斯芬克斯)/Coreseek技术来处理中文。本站将会在后续文章中对Sphinx以及Coreseek进行介绍。 备注1：目前，使用MySQL自带的全文索引时，如果查询字符串的长度过短将无法得到期望的搜索结果。MySQL全文索引所能找到的词的默认最小长度为4个字符。另外，如果查询的字符串包含停止词，那么该停止词将会被忽略。 备注2：如果可能，请尽量先创建表并插入所有数据后再创建全文索引，而不要在创建表时就直接创建全文索引，因为前者比后者的全文索引效率要高。
“答案来源于网络，供您参考” 希望以上信息可以帮到您！