innodb处理事务慢如何优化？

事务优化mysql

解决方案 »

  1.   

    1，高峰时20-23点慢处理记录偏多，主要表现在事务commit时候 超过1s记录太多。体现在前端可能一个消费动作卡一会儿。
    有如下想确认下：
    1），commit的sql语句麻烦share下，看看insert语句是否有优化的空间。
    2），这个时候你的tps是多少？2，nnodb相关的参数优化已经设置过了。
    方便share下你的innodb相关write的参数值是多少，你的mysql数据库服务器配置是什么样的？3，mysql  XA 啥的？有人应用到生产环境过吗？
    目前认识的朋友中，还没有遇到使用这个的。4，大侠们碰到事务量集中的怎么缓解压力的？
    主要是用MM机制，分库建立多个节点组，减轻单台db的write压力。
      

  2.   


    1.事务提交的sql上面已经写了 就一个insert detail的和2个update money的。insert 插入此次详情，语句没有优化的空间。
     tps大概在100左右
    2.数据库用的percona xtra cluster 配置应该还行。具体我也不清楚。一些网上说的innodb优化的参数设置我看都设置的挺好。
    3.
    4.你说mm机制是啥意思，现在问题是如何保证uid在不同的分库的表里 加钱和扣钱，要么都成功，要么都失败，保持一致性。就想atm机器转账一样。
    mysql> show global  status like '%lock%';
    +------------------------------------------+----------------------+
    | Variable_name                            | Value                |
    +------------------------------------------+----------------------+
    | Com_lock_tables                          | 0                    | 
    | Com_show_slave_status_nolock             | 0                    | 
    | Com_unlock_tables                        | 0                    | 
    | Innodb_deadlocks                         | 1                    | 
    | Innodb_row_lock_current_waits            | 0                    | 
    | Innodb_current_row_locks                 | 18446744073649205411 | 
    | Innodb_row_lock_time                     | 981764               | 
    | Innodb_row_lock_time_avg                 | 818                  | 
    | Innodb_row_lock_time_max                 | 8956                 | 
    | Innodb_row_lock_waits                    | 1199                 | 
    | Innodb_s_lock_os_waits                   | 1246167              | 
    | Innodb_s_lock_spin_rounds                | 40836241             | 
    | Innodb_s_lock_spin_waits                 | 1187943              | 
    | Innodb_x_lock_os_waits                   | 7360812              | 
    | Innodb_x_lock_spin_rounds                | 249734180            | 
    | Innodb_x_lock_spin_waits                 | 4208807              | 
    | Key_blocks_not_flushed                   | 0                    | 
    | Key_blocks_unused                        | 26792                | 
    | Key_blocks_used                          | 0                    | 
    | Performance_schema_locker_lost           | 0                    | 
    | Performance_schema_rwlock_classes_lost   | 0                    | 
    | Performance_schema_rwlock_instances_lost | 0                    | 
    | Qcache_free_blocks                       | 0                    | 
    | Qcache_total_blocks                      | 0                    | 
    | Table_locks_immediate                    | 137536652            | 
    | Table_locks_waited                       | 0                    | 
    +------------------------------------------+----------------------+
      

  3.   

    1.事务提交的sql上面已经写了 就一个insert detail的和2个update money的。insert 插入此次详情，语句没有优化的空间。
     tps大概在100左右  ？？方便贴下explain后的分析结果，我们看看。
      

  4.   

    4.你说mm机制是啥意思，现在问题是如何保证uid在不同的分库的表里 加钱和扣钱，要么都成功，要么都失败，保持一致性。就想atm机器转账一样。
    MM是双主机制。
      

  5.   

    tps大概在100左右你们tps好少啊，这根本就不是事啊。怎么会卡呢？