MySQL索引及优化
影响性能的因素
需求：一个论坛帖子总量的统计，附加要求：实时更新。从功能上来看非常容易实现，执行一条 SELECT COUNT(*) from 表名 的 Query 就可以得到结果。但是，如果我们采用不是 MyISAM 存储引擎，而是使用的 Innodb 的存储引擎，那么大家可以试想一下，如果存放帖子的表中已经有上千万的帖子的时候，执行这条 Query 语句不可能在 10 秒之内完成一次查询吧
注：没有 where 的 count(*)使用 MyISAM 要比 InnoDB 快得多。因为 MyISAM 内置了一个计数器，count(*)时它直接从计数器中读，而 InnoDB 必须扫描全表。所以在 InnoDB 上执行count(*)时一般要伴随 where，且 where 中要包含主键以外的索引列。
专门为这个功能建一个表，就只有一个字段，一条记录，就存放这个统计量，每次有新的帖子产生的时候，都将这个值增加 1。
如果帖子产生很快，在高峰时期可能每秒就有几十甚至上百个帖子新增操作
的时候，恐怕这个统计表又要成为大家的噩梦了。要么因为并发的问题造成统计结果的不准确，要么因为锁资源争用严重造成整体性能的大幅度下降。
牺牲一定的实时性，通过创建一个统计表，然后通过一个定时任务每隔一定时间段去更新一次里面的统计值，这样既可以解决统计值查询的效率问题，又可以保证不影响新发贴的效率，一举两得。
不适合在数据库中存放的： 二进制多媒体数据、超大文本数据（VARCHAR 类型的最大长度被调整到 64KB了，所以，超大文本数据存放在数据库中不仅会性能低下，还会带来空间占用的浪费问题。）
对于 Web 应用，活跃数据的数据量总是不会特别的大，有些活跃数据更是很少变化。对于这类数据，将变化相对较少的部分活跃数据通过应用层的 Cache 机制 Cache 到内存中，对性能的提升肯定是成数量级的，而且由于是活跃数据，对系统整体的性能影响也会很大。
查询语句对性能的影响：在数据库管理软件中，最大的性能瓶颈就是在于磁盘 IO，也就是数据的存取操作上面。而对于同一份数据，当我们以不同方式去寻找其中的某一点内容的时候，所需要读取的数据量可能会有天壤之别，所消耗的资源也是区别很大。
在执行 sql 语句时可以用 explain 来查看执行计划：
还可以打开 mysql 的 profiling 功能，来查看 sql 的实际执行计划
mysql> set profiling=1; show profile;
show profile CPU,BLOCK IO for query 1;
数据库 Schema 设计对性能的影响
硬件选择对性能的影响
IO 性能肯定是需要最优先考虑的一个因素：由磁盘和内存所决定。
CPU 处理能力 ：资源要相对集中很多，单台主机上所需要进行的计算量自然也就比较多。
网络设备的性能：程序的交互中传递的数据量多。
系统架构最优化，逻辑实现精简化，硬件设施理性化。商业需求合理化？
MySQL 性能优化之-索引
帮助我们快速定位数据。建立了索引，MySQL 无须任何扫描全表，即准确可找到该记录。相反，MySQL 会扫描所有记录。比是一本书前面的目录，提高查询速度。在存储引擎中实现的
----已不知曾经于何处摘录