参考：
一 大的优化方向： 数据结构优化，慢查询优化，索引优化，mysql参数设置优化
数据结构优化：先读写分离、再垂直拆分、再水平拆分！
说3点
1. 设计合适的索引,基于主键的查找,上亿数据也是很快的;
2. 反范式化设计,以空间换时间,避免join,有些join操作可以在用代码实现,没必要用数据库来实现;
3. buffer,尽量让内存大于数据.
至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈
来自：http://www.zhihu.com/question/19719997
我的问题：两个数据库，database A 和 B（be） ;每个都有两个表event和id
A
id表增长到不会超过1亿，然后会有频繁的更新.更新需要查找id值。这个亦可以分表。按照gid的不同，在程序中处理插入不同哦功能的表
每天生成一个新表，然后整体再插入总表？？
event表一直累加，会超过1亿，需要自动切表
问题：1 数据库是否是瓶颈？ 再开几个进程看数据库插入更新会不会有加速现象.多开程序的作用已经不大，很微小。所以瓶颈在数据库上了
2 瓶颈在哪里? insert时间花费0--100毫秒 ，update 100--1000ms
具体做法：
原来查看速度：
Com_insert 100
Com_update 30
以下测试再关闭程序debug日志的情况下进行
使用gprof分析程序得到 parsesql占23.5%，parseupdatesql15.5%，jsontomap占23.5，推测数据库执行占40%？
1 程序是瓶颈，开了6个进程
原来速度：
2013.09.26 。10：00 开了6个进程来跑。速度
第一次测试 第二次测试
Com_insert 489 342
Com_update 204 182
措施:加内寸，拆表
得到结论： 1 只写入event表，看会不会堵塞。不需要做这个实验，DBA自动切表就行，这样就很小。
2 数据库表很大的时候，主要考虑IO速度慢的问题，因为表太大，不能全部放进内存，所以需要硬盘IO，引起速度慢。
1 查看表大小，event表占35G，gid表占3G。
数据库设定的内存大小是10G,event是在太大了，导致频繁的磁盘IO。
A gid
TABLE_NAME | DATA_LENGTH | DATA_LENGTH+INDEX_LENGTH | TABLE_ROWS |
+-------------+-------------+--------------------------+------------+
| Mapping_gid | 2980036608 | 3606970368 | 5162861 |
+-------------+-------------+--------------------------+-----------
event
+------------------------+-------------+--------------------------+------------+
| TABLE_NAME | DATA_LENGTH | DATA_LENGTH+INDEX_LENGTH | TABLE_ROWS |
+------------------------+-------------+--------------------------+------------+
| Mapping_event_20130925 | 29944184832 | 33361494016 | 61712037 |
+------------------------+-------------+--------------------------+------------+
B gid
+-------------+-------------+--------------------------+------------+
| TABLE_NAME | DATA_LENGTH | DATA_LENGTH+INDEX_LENGTH | TABLE_ROWS |
+-------------+-------------+--------------------------+------------+
| Mapping_gid | 2173698048 | 2702901248 | 4216890 |
+-------------+-------------+--------------------------+------------+
event
------------------------+-------------+--------------------------+------------+
| TABLE_NAME | DATA_LENGTH | DATA_LENGTH+INDEX_LENGTH | TABLE_ROWS |
+------------------------+-------------+--------------------------+------------+
| Mapping_event_20130925 | 6227492864 | 6919553024 | 15018002 |
对策：把event按每天备份 ； 这样每天的event表就很小。
结果：
第一次测试
Com_insert 1158
Com_update 552
3 修改程序，原来程序insert不成功然后再update，改成insert into duplicate
可以解决的问题：1 多个进程写数据，id会跳跃性自增 2 两条变一条
各位，请教一个mysql问题。
说明：数据库id是主键，gid是唯一索引。insert into duplicate使用gid作为条件。
问题如下：
昨天我使用insert into duplicate 试验了很久、
我开了两个进程。都执行insert into duplicate语句。
进程A事实上只执行update，进程B 事实上只执行insert
单独开A时，id不变，单独开B，id是顺序增长同时开A，B，id跳跃性增长的。
可有什么解决方案推荐，使得id是顺序+1增长的？
解释： 只能说 insert into duplicate 也使得id 自增了.但是如果后来执行的是update操作，撤销了.
可设置 innodb_autoinc_lock_mode = 0 使的获取自增id的锁方式为表锁， 但是此参数是全局的（即影响所有表，且需重启数据库生效），对于高并发写入的数据，会影响插入性能，不建议
如果使用insert into duplicate 只能解决两条变一条，不能解决id问题。
我具体做法：（1）开了多份程序，提高了数据库写入和更新的速度
（2） 加大内存
未填加内存前速度 -loginfo：
Com_insert Com_update
400 160
（3）修改字段
（4）拆表