mysql 千万量级的表的优化

参考：

一  大的优化方向： 数据结构优化，慢查询优化，索引优化，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）拆表