求解困扰我几天的关于SQL查询条件、排序、各种索引等一系列问题

[iou3344]

问题背景如下：针对以下这种查询sql

SELECT Id,title,Content,summary,date,hitnum FROM TbName WHERE 1=1 and CONTAINS(title,'"aaa"') and CONTAINS(Content,'"bbb"') ORDER BY date desc,hitnum desc

以上sql所涉及的title和Content字段我已经做了全文索引或简单索引，在此前提下，我是不是再建立一个如下的有关排序的非聚集索引就可以了？这个语句这样写可以吗？需要带ORDER BY 吗？

create nonclustered index NonClu_IX_TbName_fans_ci on Contenta (date desc,hitnum desc)

问题一：以上问题是否像我上面所说的这样就可以了呢？？？

如果是的话，那么，由此我也想到下面几个一直困惑我的问题：

问题二：一般滴，当我们建立索引时，是建立排序部分的索引（ORDER BY那一部分）重要，还是建立条件部分的索引（WHERE……那一部分）更加重要？？

问题三：条件部分的索引和排序部分的索引是不是分别建立就可以了？还是最好将二者联合在一起、找出各种组合的可能并同时建立呢？那是不是意味着这是一个排列组合的问题了，有几张可能就建立几种索引吗？

问题四：查询条件字段数不一样的话（有时候是按两个条件查询、有时候是按5个条件查询），那么要对每一种组合的查询条件都建立非聚集索引吗？

问题五：当我们把作为主键的ID建立为聚集索引的基础上，我们还把各种查询和排序涉及到的其他字段都建立了全文索引，此时，是不是不管用什么字段组合构成查询的条件，都不再再对这些字段建立非聚集索引，而只需要就各种排序做索引就基本上完成了这个系统所有的索引相关的任务了呢？

问题六：存储过程又是为了什么呢？我的这个程序有一个特点就是不给用户开放任何添加数据、修改数据和删除数据的功能，只开放查询功能，这样的话，是不是就不需要存储过程了呢？



以上所有问题，大家请首先按照【问题六】所说的我的这个系统的特点来考虑和回答，这将有助于我解决我目前遇到的实际问题，但是，我还希望大家可以就一般网站的情况也解答一下，以便我了解这个问题的实质。


以上问题逐一环扣，请各位大哥逐一帮我解惑好吗？一个问题给我写一个答案好吗？或者您知道几个就回答几个也行，谢谢！

[Mr_Nice]

问题六：存储过程又是为了什么呢？ 我的这个程序有一个特点就是不给用户开放任何添加数据、修改数据和删除数据的功能， 只开放查询功能，这样的话，是不是就不需要存储过程了呢？ @@ 先说这个存储过程吧。存储过程表面上就是的一段可执行的服务端程序。代码组织结构上，它是作为安全层（可以理解为权限或封装意义上的安全）来进行处理的。也就是一种写代码的策略（lz可以搜索一下编码策略相关的知识补充一下）。最后就是它也带来了一定程度上的代码优化（主要看数据库引擎对它的支持） 问题五：当我们把作为主键的ID建立为聚集索引的基础上， 我们还把各种查询和排序涉及到的其他字段都建立了全文索引， 此时，是不是不管用什么字段组合构成查询的条件，都不再再对这些字段建立非聚集索引， 而只需要就各种排序做索引就基本上完成了这个系统所有的索引相关的任务了呢？ lz这种理解相当于想找一个万金油的办法来创建索引， 如果没有（增删改）的处理，服务器又没有容量限制的话，且表比较大（小表，一般都优化不走索引了，扫描都比索引快） lz可以穷尽索引的匹配进行创建（这是非常理想的状态，假设有10个字段，那就是10！ 3628800种索引创建方式。现实中是不会这么做的） 通常需要知道应用中主要的查询，或者是性能要求高的查询作为入手点建立对应的索引。 一般性的经验，ID并不需要作为聚集索引（你可以理解为：没有一本字典是将文字做一个数字排序，然后按数字排序一个索引的。） 通常做一个唯一索引也就够了。作为连接其它表使用。查询条件使用列及关键的输出列都需要做上索引。可以是组合的，也可以是非聚集的， 这要看具体情况。 关于全文索引，就需要lz做的更细，要了解全文索引的具体字段，才能用好全文索引。 这里涉及干扰字表的处理，这里就不多说了。 问题3、2、1 同问题5解答 问题四：查询条件字段数不一样的话（有时候是按两个条件查询、有时候是按5个条件查询）， 那么要对每一种组合的查询条件都建立非聚集索引吗？ 通常不是建立5个，而是用一个组合索引即可。（lz 查看一下组合索引定义） 注意，以上都是常规的处理办法，如果对性能有特殊要求，实际上还要考虑的更多（硬盘，文件，语句写法等等都需要综合考虑）

[吉普赛的歌]

引用 5 楼 iou3344 的回复:

[quote=引用 1 楼 yenange 的回复:] 不知道您从谁手上接了这个项目， 先把SQL Server基础的东西学一下吧。

留个问题你一个也回答不上吗？[/quote] 不是我回答不上， 是这些东西太基础， 你应该好好看书。 人家即使可以回答你， 但毕竟这些七零八碎的知识不系统。

[iou3344]

为什么有人建议说： 你这个系统既然所有数据都是导入的，那么如果只是解决查询速度和分页排序速度问题，那么，只要你的sql查询语句里面没有limit语句，完全可以把sql里的order by去掉，然后在程序里自己实现排序； 如果要根据排序分页的话，那就只能是数据库order by了，因为有limit条件限制。 他这样讲有道理吗？

[薛定谔的DBA]

问题六：存储过程作用，百度一下。 如果只是简单查询，不要存储过程也可以。对于一些复杂查询或动态查询等，借助存储过程是很好的。 问题1~5：一个表在查询中（没考虑多个相同的表），只能用一个索引，所以一张表对各个字段建索引也没什么用，只能用一个，加多了影响插入更新等。而且查询中考虑的是where条件中尽量能过滤出自己想要的数据就行，where 有多个字段条件，可以建立组合索引。组合索引中字段的位置也很重要。例如，有3个不同的查询都查一个相同的表，条件也不同，如：（栗子相对简单） where a=1 and b=100 and c=5 where b=10 and c=5 where b=1 怎么对这三个查询建立一个索引而不是分别建立3个索引？索引第一列很重要，第一列是先过滤的，3个查询条件中都有b列，b列放第一个位置；其次再查找c列，最后查找a列。所以只要建一个这样的索引 （b,c,a）即可。这主要对非聚集索引而言，聚集索引另外考虑多点。以上的条件用到了非聚集索引，但是如果查的是d列，则又从聚集索引再找一遍，不好，可以把d列包含在非聚集索引中（百度“ 包含列索引”）。最后再考虑order by 中的是否有索引，按order by 中字段排序的顺序放到非聚集索引中。

[吉普赛的歌]

不知道您从谁手上接了这个项目， 先把SQL Server基础的东西学一下吧。

[顾西昂]

解答二：对order by，group by 或者聚合函数之类的查询偏好建立聚集索引，建立非聚集所以要看改列的唯一性是否高，唯一值得百分比越高越好

[顾西昂]

解答六：存储过程稳定，只要一次成功，以后都会按这个程序运行。而且存储过程减少客户端的压力。如果怕你就一句查询语句的话，看你自己选择，如果有一系列操作的话就还是存储的好

[顾西昂]

另外说下建立索引也是有代价的，插入，删除修改时影响比较大

[iou3344]

引用 1 楼 yenange 的回复:

不知道您从谁手上接了这个项目， 先把SQL Server基础的东西学一下吧。

留个问题你一个也回答不上吗？

[中国风]

1、可以这样理解，CONTAINS用到全文检索时，同建非聚集引没关系，不需要单独再建 只有在特定环境下才有意义，如果条件为title，排序为（date ,hitnum ）时,显示列也是这3列时，为覆盖索引，不会用到聚集索引 2、在条件列建上索引，排序列是否建索引，要根据情况是否用到覆盖索引,在SELECT 中的列有没有在索引中,索引的大小也是决定查询性能的因素，对维护数据也会增大。 3、 问题2一样原理，除覆盖索引外同排序无关，可忽略，索引多少要据表的列数和频繁率，参考通常表小时维护在4~6个左右，如果表大列多，查询条件组合多，索引可增加，注意维护索引碎片整理 4、常用组合条件用一个复合索引，常用单独或组合太多条件时，单独建索引 5、全文索引不是用于排序，用于提高l模糊查询用法性能的提升，全文检索建立条件必须要依靠主健 6、存储过程便于维护管理，BL在数据库维护时，不需要升级程序，更新存储过程就行了。

[cattpon]

引用 3 楼 SugarToffee 的回复:

解答六：存储过程稳定，只要一次成功，以后都会按这个程序运行。而且存储过程减少客户端的压力。如果怕你就一句查询语句的话，看你自己选择，如果有一系列操作的话就还是存储的好

谢谢大神~

[Ny-6000]

如果对性能有特殊要求，实际上还要考虑的更多（硬盘，文件，语句写法等等都需要综合考虑） 还有,多台物理服务器, 另外,多个物理服务器,分布在多个地域,多个机房之类情况 都是需要的,---可能的话

[qq_19265511]

解决六，存储过程如前排说的，我还有一点补充，它有更高的安全性，如果你是查询，那么我想说腾讯的扣扣，你去查询，没有包装起来，一些黑客高手们是不是就看见了你的sql语句从而可以查看扣扣密码密保信息？那腾讯扣扣还有意义？