mysql 量级_mysql 千万量级的表的优化

参考：

一  大的优化方向： 数据结构优化，慢查询优化，索引优化，mysql参数设置优化

数据结构优化：先读写分离、再垂直拆分、再水平拆分！

说3点

1. 设计合适的索引,基于主键的查找,上亿数据也是很快的;

2. 反范式化设计,以空间换时间,避免join,有些join操作可以在用代码实现,没必要用数据库来实现;

3. buffer,尽量让内存大于数据.

至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈

我的问题：两个数据库，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)拆表