关于系统优化

    系统优化可不是变魔术，或施法术（若能施法术，也不错 :) ），一切都是实事求是

    抽象地说就是将不合理的规划、设计、开发调整为合理的规划、设计、开发，可能涉及数据存储结构（索引），SQL代码改写，SQL逻辑改写，操作系统与数据库配置调整，及网站服务器的缓存，到业务流程的优化，对于很多场景来说，处理掉前两三点，立杆见影的效果就出来了。基本上也遵循二八原则，就是将关键的20%部分处理好，问题就基本解决了。至于说要精益求精，若时间、成本、投入充足，亦是好事。

    对于网站应用来说，PV的响应时间是600毫秒还是200毫秒，是仅白天可用还是7*24，可能对用户与客户在表面上看起来并没多大区别，就像咱们自己打开一个EXCEL表格，是600毫秒还是200毫秒，似乎无所谓一样。但区别是存在的，而且很大。

    对于搜索引擎（如百度）来“拜访”，不同的响应时间会计入一个权重值，会影响其搜索排名。可用时间亦是，如果搜索引擎晚上来“拜访”，但你的网站却不可用，那搜索引擎只能绕道，再次降低权重，也会影响其搜索排名。

    所以，对于预算不那么紧张，最好还是多投入点尽量越快越好，可用性（7*24）越高越好

    对于数据库，在很多情况下，DBA（这里指不仅仅是做简单运维的角色）和CODER（甚至CODER升级的架构师，比较缺乏对DB的深入理解）的想法、思维区别都是很大的。就像一把菜刀，大妈大婶看到的就是切菜工具，但若是别有用心之徒看到的就是作案工具，但若是警察看到的就会是要预防点什么。。。作为最大众的应用开发者，在数据库上建表写代码完成功能，万事大吉，而且在BOSS面前价值也就体现出来了。当数据量、并发量增大时，会感觉到扛不住了，天灵灵，地灵灵，但效率却不灵。。。这时DBA角色该出场了。顺着前文的逻辑修整，称为优化。也就是将需求（既定的任务）按最有效率的方式去达成。

    另外，还有较多的误区，作为数据库平台，提供了很多特性，但是，很多特性也不一定符合很多生产场景，比如负载均衡。在SQL SERVER 2012及以后，有ALWAYSON，是不是就是理想中的均衡性能呢。。。还不是。对于实时数据与潜在的延迟数据，需要对应用规划、设计作调整，才能良好适应业务需求。单从概念上来说，数据能实时同步是个很完美的概念，但是从平衡性能的响应时间来说，实时同步会影响主服务器对客户端的响应的。所以，不能把概念当理想，当现实。