原文发布时间为：2010-11-05 —— 来源于本人的百度文章 [由搬家工具导入]
性能优化，从上面我说的两点来考虑优化，主要是以Sql为主，平台暂不介绍，我们现在使用的数据库以SQL Server2005为主。
一. 从编写的sql的习惯上来说，之前我们每个人写sql语句，直接在sql编辑区编写自己的sql语句，只要能执行成功，就万事OK了，根本就没有考虑性能方面问题。因为我们自己在开发的时候（没测试之前），数据量都是很小的，自己感觉不到。实际到客户那边，用一段时间就悲剧了。说到底还是编写的习惯上面，强烈建议（1）在要调试的sql语句前加入SET STATISTICS IO ON set statistics time on 语句，这样用EMS或者SqlServer STUDIO执行查询时会在执行的结果日志里生成表操作结果做为调试参考 ：
1. * Result : "100 rows fetched (219 ms)
2. 表 'CM_Material'。扫描计数 1，逻辑读取 386 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
3. 表 'PT_Csgl'。扫描计数 0，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。"
强烈建议（2）运行“执行计划”来检查sql执行过程是否符合预期，是否用到索引。
在EMS中点"Explain Query " ;Studio里有“显示估计的执行计划”按钮
如下图就是一个执行计划的效果图，执行效果可以清楚看到执行过程
（二）从SQL语句以及设计表的规则上：
1.尽量避免在WHERE子句中对字段进行函数或表达式操作，这将导致引擎放弃使用索引而进行全表扫描；
2.尽量避免使用!=或＜＞、IS NULL或IS NOT NULL、IN ，NOT IN等这样的操作符,因为这会使系统无法使用索引,而只能直接搜索表中的数据。
3.尽量使用数字型字段，我们开发人员大都喜欢把包含数值信息的字段设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
4.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。
5.数据类型尽量小，这里的尽量小是指在满足可以预见的未来需求的前提下的。
6.少用TEXT和IMAGE，二进制字段的读写是比较慢的，而且，读取的方法也不多，大部分情况下最好不用。
7.自增字段要慎用，不利于数据迁移。
这里还只是对sql方面的简单总结，先写到这吧，呵呵。以后慢慢放些优化的测试实例