共计 1062 个字符，预计需要花费 3 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关量比较多的数据库该怎样优化，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
查询的优化
保证在实现功能的基础上，尽量减少对数据库的访问次数；通过搜索参数，尽量减少对表的访问行数, 最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用 SQL 时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；在查询时，不要过多地使用通配符如 SELECT*FROMT1 语句，要用到几列就选择几列如：SELECTCOL1,COL2FROMT1；在可能的情况下尽量限制尽量结果集行数如：SELECTTOP300COL1,COL2,COL3FROMT1, 因为某些情况下用户是不需要那么多的数据的。
在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。
SQL 语句在 SQLSERVER 中是如何执行的，他们担心自己所写的 SQL 语句会被 SQLSERVER 误解。比如：
select * from table1 where name = zhangsan and tID 10000
和执行:
select * from table1 wheret ID 10000 and name = zhangsan
一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果 tID 是一个聚合索引，那么后一句仅仅从表的 10000 条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个 name= zhangsan 的，而后再根据限制条件条件 tID 10000 来提出查询结果。
事实上，这样的担心是不必要的。SQLSERVER 中有一个“查询分析优化器”，它可以计算出 where 子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。虽然查询优化器可以根据 where 子句自动的进行查询优化，但有时查询优化器就会不按照您的本意进行快速查询。
在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。
上述就是丸趣 TV 小编为大家分享的量比较多的数据库该怎样优化了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
