51Testing软件测试论坛

标题: 按月分区的方法和性能比较 [打印本页]
作者: TimiZheng    时间: 2019-10-16 15:48
标题: 按月分区的方法和性能比较
按月分区方法的比较
1、事出有因

在生产系统中发现在高并发时，分区表常常被锁住，而记录的锁非常奇怪，是最早分区中的一个数据，而实际删除的时候都限制了分区字段的值，这个值是一个between A and B ，A B之间并不包括最早分区。innodb的行级锁是按索引来的，无论如何都不应该会将他的这行记录锁住。

说明存在问题：我们的分区可能有问题或者mysql本身的bug

以下主要针对分区方式的分区解析和行锁进行的测试。

2、表结构 -按月分区的两种方式，第一种是按照 日期/100 得到的结果进行分区
  1. CREATE TABLE `test_stock_history_1` (
  2.   `rtime` bigint(20) unsigned NOT NULL,
  3.   `oid` int(10) unsigned DEFAULT NULL,
  4.   `fund_key` bigint(20) unsigned NOT NULL,
  5.   `trans_date` date NOT NULL DEFAULT '1700-01-01',
  6. ......
  7. ......
  8.   `createtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

  10.   `updatetime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  11.   `broker` int(10) DEFAULT NULL,
  12.   `terminal` char(3) DEFAULT NULL,
  13.   `dealway` char(3) DEFAULT NULL,
  14.   `type1` char(10) DEFAULT NULL,
  15.   `type2` char(20) DEFAULT NULL,
  16.   UNIQUE KEY `idx_sh_fto` (`fund_key`,`trans_date`,`oid`) USING BTREE,
  17.   KEY `idx_sh_fts` (`fund_key`,`trans_date`,`stock_code`) USING BTREE
  18. ) ENGINE=InnoDB DEFAULT CHARSET=utf8
  19. |
复制代码
第二种分区是直接按照日期的方式取值范围进行分区：
  1. | test_stock_history_2 | CREATE TABLE `test_stock_history_2` (
  2.   `rtime` bigint(20) unsigned NOT NULL,
  3.   `oid` int(10) unsigned DEFAULT NULL,
  4.   `fund_key` bigint(20) unsigned NOT NULL,
  5.   `trans_date` date NOT NULL DEFAULT '1700-01-01',
  6. ......
  7. ......  
  8. `createtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  9.   `updatetime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  10.   `broker` int(10) DEFAULT NULL,
  11.   `terminal` char(3) DEFAULT NULL,
  12.   `dealway` char(3) DEFAULT NULL,
  13.   `type1` char(10) DEFAULT NULL,
  14.   `type2` char(20) DEFAULT NULL,
  15.   UNIQUE KEY `idx_sh_fto` (`fund_key`,`trans_date`,`oid`) USING BTREE,
  16.   KEY `idx_sh_fts` (`fund_key`,`trans_date`,`stock_code`) USING BTREE
  17. ) ENGINE=InnoDB DEFAULT CHARSET=utf8
  18. |
复制代码

以上两种表，除了分区方式不同，其他字段、索引均相同，每个分区中存放的数据也相同

3、按照索引的执行计划解释

  1. explain partitions (select *  from  test_stock_history_1 where  fund_key=3100120 and trans_date >= '2016-01-01' and trans_date<= '2016-01-03' );
  2. +----+-------------+----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+-----------------------+------------+---------+------+------+-------------+
  3. | id | select_type | table                | partitions                                                                                                                                                                                                                                                                               | type  | possible_keys         | key        | key_len | ref  | rows | Extra       |
  4. +----+-------------+----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+-----------------------+------------+---------+------+------+-------------+
  5. |  1 | SIMPLE      | test_stock_history_1 | p_201407,p_201408,p_201409,p_201410,p_201411,p_201412,p_201501,p_201502,p_201503,p_201504,p_201505,p_201506,p_201507,p_201508,p_201509,p_201510,p_201511,p_201512,p_201601,p_201602,p_201603,p_201604,p_201605,p_201606,p_201607,p_201608,p_201609,p_201610,p_201611,p_201612,p_catchall | range | idx_sh_fto,idx_sh_fts | idx_sh_fto | 11      | NULL |   10 | Using where |
  6. +----+-------------+----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------+-----------------------+------------+---------+------+------+-------------+
  7. 发现是所有分区。

  9. mysql> explain partitions (select *  from  test_stock_history_2 where  fund_key=3100120 and trans_date >= '2016-01-01' and trans_date<= '2016-01-03' );
  10. +----+-------------+----------------------+------------+-------+-----------------------+------------+---------+------+------+-------------+
  11. | id | select_type | table                | partitions | type  | possible_keys         | key        | key_len | ref  | rows | Extra       |
  12. +----+-------------+----------------------+------------+-------+-----------------------+------------+---------+------+------+-------------+
  13. |  1 | SIMPLE      | test_stock_history_2 | p_201601   | range | idx_sh_fto,idx_sh_fts | idx_sh_fto | 11      | NULL |    1 | Using where |
  14. +----+-------------+----------------------+------------+-------+-----------------------+------------+---------+------+------+-------------+
复制代码
2、查询解释
尽管上面的分区表解释不同，但是他们的执行计划解释是完全相同的

这种分区方式看起来能够定位具体的分区，看起来好像比较好，需要进行测试。

两个表同时导入3千万数据(loaddata) ,花费时间几乎一致。

删除



3、事务锁的情况

3.1、表一方式的锁

从监控的结果看，是锁住了一条毫无关系的一行记录。并且在实验环境下这种情况是完全可重现的

  1. 执行事务1
  2. start transaction;
  3. delete from test_stock_history_1 where fund_key = 3100190 and trans_date between '2016-05-01' and '2016-05-20';


  6. 执行事务2
  7. start transaction;
  8. delete from test_stock_history_1 where fund_key = 3100190 and trans_date between '2016-04-01' and '2016-04-20';
复制代码

原来个人认为这两条记录毫无关系，按照innodb的行锁规则，1和2无关，2是不会被锁的，但是实际执行中被锁住了。
  1. 检查事务和锁表的情况：
  2. select * from innodb_trx \G
  3. *************************** 1. row ***************************
  4.                     trx_id: 2798703
  5.                  trx_state: LOCK WAIT
  6.                trx_started: 2016-06-27 18:36:17
  7.      trx_requested_lock_id: 2798703:328:17:459
  8.           trx_wait_started: 2016-06-27 18:36:17
  9.                 trx_weight: 2
  10.        trx_mysql_thread_id: 2
  11.                  trx_query: delete from test_stock_history_1 where fund_key = 3100190 and trans_date between '2016-04-01' and '2016-04-20'
  12.        trx_operation_state: starting index read
  13.          trx_tables_in_use: 31
  14.          trx_tables_locked: 31
  15.           trx_lock_structs: 2
  16.      trx_lock_memory_bytes: 360
  17.            trx_rows_locked: 1
  18.          trx_rows_modified: 0
  19.    trx_concurrency_tickets: 0
  20.        trx_isolation_level: REPEATABLE READ
  21.          trx_unique_checks: 1
  22.     trx_foreign_key_checks: 1
  23. trx_last_foreign_key_error: NULL
  24. trx_adaptive_hash_latched: 0
  25. trx_adaptive_hash_timeout: 10000
  26.           trx_is_read_only: 0
  27. trx_autocommit_non_locking: 0
  28. *************************** 2. row ***************************
  29.                     trx_id: 2798701
  30.                  trx_state: RUNNING
  31.                trx_started: 2016-06-27 18:35:01
  32.      trx_requested_lock_id: NULL
  33.           trx_wait_started: NULL
  34.                 trx_weight: 107
  35.        trx_mysql_thread_id: 3
  36.                  trx_query: NULL
  37.        trx_operation_state: NULL
  38.          trx_tables_in_use: 0
  39.          trx_tables_locked: 0
  40.           trx_lock_structs: 92
  41.      trx_lock_memory_bytes: 13864
  42.            trx_rows_locked: 84
  43.          trx_rows_modified: 15
  44.    trx_concurrency_tickets: 0
  45.        trx_isolation_level: REPEATABLE READ
  46.          trx_unique_checks: 1
  47.     trx_foreign_key_checks: 1
  48. trx_last_foreign_key_error: NULL
  49. trx_adaptive_hash_latched: 0
  50. trx_adaptive_hash_timeout: 10000
  51.           trx_is_read_only: 0
  52. trx_autocommit_non_locking: 0
  53. 2 rows in set (0.00 sec)
复制代码

  1. mysql> select * from innodb_locks \G
  2. *************************** 1. row ***************************
  3.     lock_id: 2798703:328:17:459
  4. lock_trx_id: 2798703
  5.   lock_mode: X
  6.   lock_type: RECORD
  7. lock_table: `test`.`test_stock_history_1`
  8. lock_index: idx_sh_fto
  9. lock_space: 328
  10.   lock_page: 17
  11.    lock_rec: 459
  12.   lock_data: 3100310, 1031394, 0
  13. *************************** 2. row ***************************
  14.     lock_id: 2798701:328:17:459
  15. lock_trx_id: 2798701
  16.   lock_mode: X
  17.   lock_type: RECORD
  18. lock_table: `test`.`test_stock_history_1`
  19. lock_index: idx_sh_fto
  20. lock_space: 328
  21.   lock_page: 17
  22.    lock_rec: 459
  23.   lock_data: 3100310, 1031394, 0
  24. 2 rows in set (0.00 sec)
复制代码



文章来源：沧海大声啸的博客作者：Kervin（博为峰网校讲师）




作者: TimiZheng    时间: 2019-10-16 15:51
  1. mysql> select * from innodb_lock_waits  \G
  2. *************************** 1. row ***************************
  3. requesting_trx_id: 2798703
  4. requested_lock_id: 2798703:328:17:459
  5.   blocking_trx_id: 2798701
  6. blocking_lock_id: 2798701:328:17:459
  7. 1 row in set (0.00 sec)
复制代码

从上面的结果看被锁住的记录在p_201407分区，这是第一个分区
索引对应的值是：3100310, 1031394, 0
但删除的时候跟这个毫无关系，无论fund_key还是分区。
  1. mysql> select fund_key,trans_date,oid from test.test_stock_history_1 limit 1;
  2. +----------+------------+------+
  3. | fund_key | trans_date | oid  |
  4. +----------+------------+------+
  5. |  3100310 | 2014-07-02 |    0 |
  6. +----------+------------+------+
复制代码

出来就是这个被锁住的记录
作者: TimiZheng    时间: 2019-10-16 15:54
怀疑：如果无论是谁删除锁住的都是这行记录，那岂不是变成了全表锁是一个道理了？
验证：继续按事务1锁住，执行事务3：
mysql> delete From test_stock_history_1 where fund_key =4414000 and trans_date between '2016-03-01' and '2016-03-31';
Query OK, 18 rows affected (0.00 sec)
能够非常快的

再开窗口，继续执行事务4
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> delete From test_stock_history_1 where fund_key =4414000 and trans_date between '2016-03-01' and '2016-03-31';

事务4被阻塞了，查看锁：
  1. mysql> select * from innodb_trx \G
  2. *************************** 1. row ***************************
  3.                     trx_id: 2798734
  4.                  trx_state: LOCK WAIT
  5.                trx_started: 2016-06-27 19:12:46
  6.      trx_requested_lock_id: 2798734:328:2219:258
  7.           trx_wait_started: 2016-06-27 19:12:46
  8.                 trx_weight: 2
  9.        trx_mysql_thread_id: 7
  10.                  trx_query: delete From test_stock_history_1 where fund_key =4414000 and trans_date between '2016-03-01' and '2016-03-31'
  11.        trx_operation_state: starting index read
  12.          trx_tables_in_use: 31
  13.          trx_tables_locked: 31
  14.           trx_lock_structs: 2
  15.      trx_lock_memory_bytes: 360
  16.            trx_rows_locked: 1
  17.          trx_rows_modified: 0
  18.    trx_concurrency_tickets: 0
  19.        trx_isolation_level: REPEATABLE READ
  20.          trx_unique_checks: 1
  21.     trx_foreign_key_checks: 1
  22. trx_last_foreign_key_error: NULL
  23. trx_adaptive_hash_latched: 0
  24. trx_adaptive_hash_timeout: 10000
  25.           trx_is_read_only: 0
  26. trx_autocommit_non_locking: 0
  27. *************************** 2. row ***************************
  28.                     trx_id: 2798733
  29.                  trx_state: RUNNING
  30.                trx_started: 2016-06-27 19:11:33
  31.      trx_requested_lock_id: NULL
  32.           trx_wait_started: NULL
  33.                 trx_weight: 91
  34.        trx_mysql_thread_id: 2
  35.                  trx_query: NULL
  36.        trx_operation_state: NULL
  37.          trx_tables_in_use: 0
  38.          trx_tables_locked: 0
  39.           trx_lock_structs: 86
  40.      trx_lock_memory_bytes: 13864
  41.            trx_rows_locked: 64
  42.          trx_rows_modified: 5
  43.    trx_concurrency_tickets: 0
  44.        trx_isolation_level: REPEATABLE READ
  45.          trx_unique_checks: 1
  46.     trx_foreign_key_checks: 1
  47. trx_last_foreign_key_error: NULL
  48. trx_adaptive_hash_latched: 0
  49. trx_adaptive_hash_timeout: 10000
  50.           trx_is_read_only: 0
  51. trx_autocommit_non_locking: 0
  52. *************************** 3. row ***************************
  53.                     trx_id: 2798725
  54.                  trx_state: RUNNING
  55.                trx_started: 2016-06-27 18:49:50
  56.      trx_requested_lock_id: NULL
  57.           trx_wait_started: NULL
  58.                 trx_weight: 101
  59.        trx_mysql_thread_id: 3
  60.                  trx_query: NULL
  61.        trx_operation_state: NULL
  62.          trx_tables_in_use: 0
  63.          trx_tables_locked: 0
  64.           trx_lock_structs: 86
  65.      trx_lock_memory_bytes: 13864
  66.            trx_rows_locked: 84
  67.          trx_rows_modified: 15
  68.    trx_concurrency_tickets: 0
  69.        trx_isolation_level: REPEATABLE READ
  70.          trx_unique_checks: 1
  71.     trx_foreign_key_checks: 1
  72. trx_last_foreign_key_error: NULL
  73. trx_adaptive_hash_latched: 0
  74. trx_adaptive_hash_timeout: 10000
  75.           trx_is_read_only: 0
  76. trx_autocommit_non_locking: 0
  77. 3 rows in set (0.00 sec)
复制代码

  1. mysql> select * from innodb_locks  \G
  2. *************************** 1. row ***************************
  3.     lock_id: 2798734:328:2219:258
  4. lock_trx_id: 2798734
  5.   lock_mode: X
  6.   lock_type: RECORD
  7. lock_table: `test`.`test_stock_history_1`
  8. lock_index: idx_sh_fto
  9. lock_space: 328
  10.   lock_page: 2219
  11.    lock_rec: 258
  12.   lock_data: 4414290, 1031393, 0
  13. *************************** 2. row ***************************
  14.     lock_id: 2798733:328:2219:258
  15. lock_trx_id: 2798733
  16.   lock_mode: X
  17.   lock_type: RECORD
  18. lock_table: `test`.`test_stock_history_1`
  19. lock_index: idx_sh_fto
  20. lock_space: 328
  21.   lock_page: 2219
  22.    lock_rec: 258
  23.   lock_data: 4414290, 1031393, 0
  24. 2 rows in set (0.00 sec)

  26. mysql> select * from innodb_lock_waits  \G
  27. *************************** 1. row ***************************
  28. requesting_trx_id: 2798734
  29. requested_lock_id: 2798734:328:2219:258
  30.   blocking_trx_id: 2798733
  31. blocking_lock_id: 2798733:328:2219:258
  32. 1 row in set (0.00 sec)
复制代码

从这个上面看，他锁住的记录同样和我们操作的记录完全无关  fund_key= 4414290

那我们就直接删除4414290 的记录看看
mysql>  delete From test_stock_history_1 where fund_key = 4414290  and trans_date between '2014-07-01' and '2014-07-31';

这条也是被锁住

所以这些信息并没有欺骗我们，这行是真的被锁住了。

总结：从表一上相关的锁情况看，分区字段进行了一次计算之后，锁已经乱了，这可能是个bug，也可能是其他原因，我并没有找出他的原因所在。（如果有兄弟能查出原因，希望能告知我一声）
只从结果上，锁住的行范围变了，可能会有多种fund_key 对应锁到同一行了，在我们系统中高并发时可能看到这样的锁监控记录。
作者: TimiZheng    时间: 2019-10-16 15:57
3.2 表二的事务锁情况
表二的数据结构和数据完全一样，但是分区方式不同。
做同样的事务操作分析
事务1
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
  1. mysql> delete from test_stock_history_2 where fund_key = 3100190 and trans_date between '2016-05-01' and '2016-05-20';
  2. Query OK, 15 rows affected (0.00 sec)
复制代码

  1. 事务2
  2. mysql> start transaction;
  3. Query OK, 0 rows affected (0.00 sec)


  6. mysql> delete from test_stock_history_2 where fund_key = 3100190 and trans_date between '2016-04-01' and '2016-04-20';
  7. Query OK, 11 rows affected (0.00 sec)
复制代码


事务1和事务2之间，因为日期不同，按照行锁的规则，他们并不会互斥，所以事务2非常顺利的执行下去了
继续在事务2下执行
  1. mysql> delete from test_stock_history_2 where fund_key = 3100190 and trans_date between '2016-05-01' and '2016-05-20';
复制代码
作者: TimiZheng    时间: 2019-10-16 16:00
这条就被锁住了
  1. mysql> select * from innodb_trx \G
  2. *************************** 1. row ***************************
  3.                     trx_id: 2798760
  4.                  trx_state: LOCK WAIT
  5.                trx_started: 2016-06-27 19:39:57
  6.      trx_requested_lock_id: 2798760:381:18:2
  7.           trx_wait_started: 2016-06-27 19:41:27
  8.                 trx_weight: 22
  9.        trx_mysql_thread_id: 2
  10.                  trx_query: delete from test_stock_history_2 where fund_key = 3100190 and trans_date between '2016-05-01' and '2016-05-20'
  11.        trx_operation_state: starting index read
  12.          trx_tables_in_use: 1
  13.          trx_tables_locked: 1
  14.           trx_lock_structs: 11
  15.      trx_lock_memory_bytes: 2936
  16.            trx_rows_locked: 25
  17.          trx_rows_modified: 11
  18.    trx_concurrency_tickets: 0
  19.        trx_isolation_level: REPEATABLE READ
  20.          trx_unique_checks: 1
  21.     trx_foreign_key_checks: 1
  22. trx_last_foreign_key_error: NULL
  23. trx_adaptive_hash_latched: 0
  24. trx_adaptive_hash_timeout: 10000
  25.           trx_is_read_only: 0
  26. trx_autocommit_non_locking: 0
  27. *************************** 2. row ***************************
  28.                     trx_id: 2798759
  29.                  trx_state: RUNNING
  30.                trx_started: 2016-06-27 19:39:46
  31.      trx_requested_lock_id: NULL
  32.           trx_wait_started: NULL
  33.                 trx_weight: 25
  34.        trx_mysql_thread_id: 3
  35.                  trx_query: NULL
  36.        trx_operation_state: NULL
  37.          trx_tables_in_use: 0
  38.          trx_tables_locked: 0
  39.           trx_lock_structs: 10
  40.      trx_lock_memory_bytes: 2936
  41.            trx_rows_locked: 32
  42.          trx_rows_modified: 15
  43.    trx_concurrency_tickets: 0
  44.        trx_isolation_level: REPEATABLE READ
  45.          trx_unique_checks: 1
  46.     trx_foreign_key_checks: 1
  47. trx_last_foreign_key_error: NULL
  48. trx_adaptive_hash_latched: 0
  49. trx_adaptive_hash_timeout: 10000
  50.           trx_is_read_only: 0
  51. trx_autocommit_non_locking: 0
  52. 2 rows in set (0.00 sec)
复制代码
  1. mysql> select * from innodb_locks  \G
  2. *************************** 1. row ***************************
  3.     lock_id: 2798760:381:18:2
  4. lock_trx_id: 2798760
  5.   lock_mode: X
  6.   lock_type: RECORD
  7. lock_table: `test`.`test_stock_history_2`
  8. lock_index: idx_sh_fto
  9. lock_space: 381
  10.   lock_page: 18
  11.    lock_rec: 2
  12.   lock_data: 3100190, 1032357, 0
  13. *************************** 2. row ***************************
  14.     lock_id: 2798759:381:18:2
  15. lock_trx_id: 2798759
  16.   lock_mode: X
  17.   lock_type: RECORD
  18. lock_table: `test`.`test_stock_history_2`
  19. lock_index: idx_sh_fto
  20. lock_space: 381
  21.   lock_page: 18
  22.    lock_rec: 2
  23.   lock_data: 3100190, 1032357, 0
  24. 2 rows in set (0.00 sec)
复制代码
  1. mysql> select * from innodb_lock_waits  \G
  2. *************************** 1. row ***************************
  3. requesting_trx_id: 2798760
  4. requested_lock_id: 2798760:381:18:2
  5.   blocking_trx_id: 2798759
  6. blocking_lock_id: 2798759:381:18:2
  7. 1 row in set (0.00 sec)
复制代码


从上面看他锁住的行信息，  lock_data: 3100190, 1032357, 0
这个就是正确的。

插入和删除测试：
插入性能基本相同
删除测试:
作者: TimiZheng    时间: 2019-10-16 16:02
删除一次之后，已经没有数据了，再进行一次删除，因为已经全部没有数据，所以这个时候其实都是空的
测试删除的语句delete from table where fund_key between A and B ;
测试结果：
表1 ：
当只有一个进程时37.5秒

1467193557.537469388:start execute delete /root/parttest/sqldir/delesql0.sql
1467193595.066862604:end execute delete /root/parttest/sqldir/delesql0.sql. execute time = 37529
同时两个进程,42秒
1467193905.955952753:end execute delete /root/parttest/sqldir/delesql1.sql. execute time = 42855
1467193907.442418878:end execute delete /root/parttest/sqldir/delesql0.sql. execute time = 44342
同时3个进程47.8秒
1467200320.559988788:end execute delete /root/parttest/sqldir/delesql1.sql. execute time = 47822
1467200320.559988144:end execute delete /root/parttest/sqldir/delesql2.sql. execute time = 47822
1467200320.560782711:end execute delete /root/parttest/sqldir/delesql0.sql. execute time = 47823
同时10个进程，需要53.9
同时50个进程，需要74.8秒
发现进程数量越多，花费的时间越长，完全出乎我们的意料
这个结果完全超出我们的医疗。
当50个进程的时候，查锁记录情况，查到48个记录。
  1. mysql> select * from information_schema.innodb_locks \G
  2. *************************** 1. row ***************************
  3.     lock_id: 5311932:328:17:459
  4. lock_trx_id: 5311932
  5.   lock_mode: X
  6.   lock_type: RECORD
  7. lock_table: `test`.`test_stock_history_1`
  8. lock_index: idx_sh_fto
  9. lock_space: 328
  10.   lock_page: 17
  11.    lock_rec: 459
  12.   lock_data: 3100310, 1031394, 0
  13. *************************** 2. row ***************************
  14.     lock_id: 5311931:328:17:459
  15. lock_trx_id: 5311931
  16.   lock_mode: X
  17.   lock_type: RECORD
  18. lock_table: `test`.`test_stock_history_1`
  19. lock_index: idx_sh_fto
  20. lock_space: 328
  21.   lock_page: 17
  22.    lock_rec: 459
  23.   lock_data: 3100310, 1031394, 0
  24. *************************** 3. row ***************************
  25.     lock_id: 5311930:328:17:459
  26. lock_trx_id: 5311930
  27.   lock_mode: X
  28.   lock_type: RECORD
  29. lock_table: `test`.`test_stock_history_1`
  30. lock_index: idx_sh_fto
  31. lock_space: 328
  32.   lock_page: 17
  33.    lock_rec: 459
  34.   lock_data: 3100310, 1031394, 0
  35. *************************** 4. row ***************************
  36. 总共48条锁记录
复制代码


4、结论
从上面的结果来看，对分区字段进行计算后作为分区字段的方式，会有弊端，只要出现2个方面：

1 是当条件是between 或者> < 组成的，那么分区信息就会错误。
2 行锁位置出现了问题，可能导致更大范围的锁，最终影响到高并发时的性能。
所以建议尽可能的使用原始值进行分区。



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2