sybase 性能优化经验谈

使用sybase数据库多年，有些经验，在数据库部署配置得当，平时监控维护做到位情况下，除此之外数据库的性能问题80%将会是由sql语句引起。
在编写sql语句时候，个人经验，以下几个问题中有大部分跟编写sql有关，必须引起重视。
   经验一、where 条件左边最好不要使用函数，比如：
           select ...     where     datediff(day,date_column,getdate())>0
           这样即使在date_column列上建立了索引，也可能不会使用索引，而使用全表扫描。
           这样的语句要重新规划设计，保证不使用函数也能够实现。通过修改，一个系统过程的运行效率提高大约几十倍甚至上百倍！此外不要使用诸如like '%ab',不能充分利用索引，而要在%前加字符。
  经验二、两个比较字段最好使用相同数据类型，而不是兼容数据类型。比如 int 与 numeric（感觉一般不是太明显）。
  经验三、复合索引的非前导列做条件时，基本没有起到索引的作用。
         比如 create index idx_tablename_ab on tablename(a,b) 
         update tablename set c = XX where b>= XXX and ... 
         在这个语句中，只用了索引列b而没用索引列a做查询条件，基本上索引没有发挥作用。 导致表扫描引起blocking 甚至运行十几分钟后报告失败。
         一定要认真检查 改正措施： 在接口中附加条件 
         update tablename set c = XX  where  a = XXX  and b>= XXX 
         或者建立索引类似于 
         create index idx_tablename_ba on tablename(b,a) 
  经验四、 多个大表的关联查询，如果性能不好，并且其中一个大表中取的数据比较少，可以考虑将查询分两步执行。
          先将一个大表中的少部分数据 select * into #tmp from large_table where ...
          然后再用 #tmp 去做关联，效果可能会好不少。（前提：生成 #tmp表时，访问large_table 用到了比较好的索引，速度比较快）
  经验五、 tempdb 的使用。
           最好多用 select  into ，这样不记日志 ，尤其是有大量数据的报表时。虽然写起来麻烦，但值得。
           create table #tmp (......)这样写性能不好。尤其是大量使用时，容易发生tempdb 争用。
  经验六、 系统级别的参数设置     
          一定要估计一下，不要配置太多，占用资源 ，配置太少，发生性能问题。
          连接数，索引打开个数、锁个数 等、 当然 ，内存配置不要有明显的问题，比如，procedure cache 
          不够 （一般缺省20%，如果觉得太多，可以减少一些）。如果做报表经常使用大数据量读，可以考虑使用 
          16K data cache 
  经验七、索引的建立，很重要。
          clustered index     /nonclustered index 的差异，自己要搞清楚。各适用场合，另外如果
          clustered index 不允许 重复数，也一定要说明。
          索引设计是以为数据访问快速为原则的，不能 完全参照数据逻辑设计的，逻辑设计时的一些东西，
          可能对物理访问不起作用
  经验八、定期统计量数据的更新，更新频率看数据变化速度，一般数据发生10-15%左右变化就要进行统计量的更新，否则索引容易失效，update statistics
  经验九、定期进行regorg rebuild，回收索引页上分配而未用的空间，删除前推行，或者根据所建聚簇索引（如果存在）重新将表中所有数据行写入新的页，使索引页的物理存放尽可能的连续，提高其访问效率。
          例如，长期的表数据更新操作，使得包含索引数据的索引页的物理存放空间出现碎片，如同表的数据页空间碎片整理一样，可以通过该命令重建表上的索引，整理碎 片，提高空间的存放和访问效率。   
          基本语法：   
          reorg   rebuild   table_name   [index_name]   
  经验十、别遗忘sp_recompile,让使用该表的存储过程和触发器在下次运行时重新编译。在添加索引或对数据库进行其它影响统计信息的更改时，表的存储过程和触发器可能会失效。通过重新编译可将查询优化到最有效的状态。
          sp_recompile tablename 使用该表的存储过程和触发器在下次运行时重新编译。
  经验十一、强制索引使用 
         如果怀疑有表访问时不是使用索引，而且这些条件字段上建立了合适的索引,可以强制使用
         select * from tableA (index idx_name) where ...
         这个对一些报表程序可能比较有用。
  经验十二、找一个好的监视工具 
         工欲善其事，必先利其器，一点都不错呀。
         我用 DBArtisan ,监视哪些表被锁定时间长， blocking 等
         还有 sp_object_status 20:00:00 ， sp_sysmon 20:00:00 等
  经验十三： 综合以上对IN/EXISTS的讨论，我们可以得出一个基本通用的结论：IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。
         另外，系统中确认不使用的中间数据，可以进行转移。这些要看系统的情况哦

         最后祝你好运气。

以上为个人经验，欢迎批评指正！     
     呵呵 写完后忘记一个     一定要注意热点表 ，这是影响并发问题的一个潜在因素。！解决方法： 行锁模式 如果表的行比较小，可以故意增加一些不用的字段
     比如     char(200)     让一页中存放的行不要太多。