我们的项目中有好多不等于的情况。今天写这篇文章简单的分析一下怎么个优化法。这里的分表逻辑是根据t_group表的user_name组的个数来分的。
因为这种情况单独user_name字段上的索引就属于烂索引。起不了啥名明显的效果。
1、试验PROCEDURE.DELIMITER $$
DROP PROCEDURE `t_girl`.`sp_split_table`$$
CREATE PROCEDURE `t_girl`.`sp_split_table`()
BEGIN
declare done int default 0;
declare v_user_name varchar(20) default '';
declare v_table_name varchar(64) default '';
-- Get all users' name.
declare cur1 cursor for select user_name from t_group group by user_name;
-- Deal with error or warnings.
declare continue handler for 1329 set done = 1;
-- Open cursor.
open cur1;
while done <> 1
do
fetch cur1 into v_user_name;
if not done then
-- Get table name.
set v_table_name = concat('t_group_',v_user_name);
-- Create new extra table.
set @stmt = concat('create table ',v_table_name,' like t_group');
prepare s1 from @stmt;
execute s1;
drop prepare s1;
-- Load data into it.
set @stmt = concat('insert into ',v_table_name,' select * from t_group where user_name = ''',v_user_name,'''');
prepare s1 from @stmt;
execute s1;
drop prepare s1;
end if;
end while;
-- Close cursor.
close cur1;
-- Free variable from memory.
set @stmt = NULL;
END$$
DELIMITER ;
2、试验表。
我们用一个有一千万条记录的表来做测试。mysql> select count(*) from t_group;
+----------+
| count(*) |
+----------+
| 10388608 |
+----------+
1 row in set (0.00 sec)
表结构。
mysql> desc t_group;
+-------------+------------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------------+------+-----+-------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| money | decimal(10,2) | NO | | | |
| user_name | varchar(20) | NO | MUL | | |
| create_time | timestamp | NO | | CURRENT_TIMESTAMP | |
+-------------+------------------+------+-----+-------------------+----------------+
4 rows in set (0.00 sec)
索引情况。
mysql> show index from t_group;
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
|
Table | Non_unique | Key_name | Seq_in_index | Column_name |
Collation | Cardinality | Sub_part | Packed | Null | Index_type |
Comment |
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
|
t_group | 0 | PRIMARY | 1 | id |
A | 10388608 | NULL | NULL | | BTREE
| |
| t_group | 1 | idx_user_name |
1 | user_name | A | 8 | NULL | NULL | |
BTREE | |
| t_group | 1 | idx_combination1
| 1 | user_name | A | 8 | NULL |
NULL | | BTREE | |
| t_group | 1 |
idx_combination1 | 2 | money | A | 3776
| NULL | NULL | | BTREE | |
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
4 rows in set (0.00 sec)
PS:
idx_combination1 这个索引是必须的,因为要对user_name来GROUP BY。此时属于松散索引扫描!当然完了后你可以干掉她。
idx_user_name 这个索引是为了加快单独执行constant这种类型的查询。
我们要根据用户名来分表。
mysql> select user_name from t_group where 1 group by user_name;
+-----------+
| user_name |
+-----------+
| david |
| leo |
| livia |
| lucy |
| sarah |
| simon |
| sony |
| sunny |
+-----------+
8 rows in set (0.00 sec)
所以结果表应该是这样的。mysql> show tables like 't_group_%';
+------------------------------+
| Tables_in_t_girl (t_group_%) |
+------------------------------+
| t_group_david |
| t_group_leo |
| t_group_livia |
| t_group_lucy |
| t_group_sarah |
| t_group_simon |
| t_group_sony |
| t_group_sunny |
+------------------------------+
8 rows in set (0.00 sec)
3、对比结果。mysql> select count(*) from t_group where user_name = 'david';
+----------+
| count(*) |
+----------+
| 1298576 |
+----------+
1 row in set (1.71 sec)
执行了将近2秒。mysql> select count(*) from t_group_david;
+----------+
| count(*) |
+----------+
| 1298576 |
+----------+
1 row in set (0.00 sec)
几乎是瞬间的。mysql> select count(*) from t_group where user_name <> 'david';
+----------+
| count(*) |
+----------+
| 9090032 |
+----------+
1 row in set (9.26 sec)
执行了将近10秒,可以想象,这个是实际的项目中是不能忍受的。mysql> select (select count(*) from t_group) - (select count(*) from t_group_david) as total;
+---------+
| total |
+---------+
| 9090032 |
+---------+
1 row in set (0.00 sec)
几乎是瞬间的。我们来看看聚集函数。对于原表的操作。mysql> select min(money),max(money) from t_group where user_name = 'david';
+------------+------------+
| min(money) | max(money) |
+------------+------------+
| -6.41 | 500.59 |
+------------+------------+
1 row in set (0.00 sec)
最小,最大值都是FULL INDEX SCAN。所以是瞬间的。mysql> select sum(money),avg(money) from t_group where user_name = 'david';
+--------------+------------+
| sum(money) | avg(money) |
+--------------+------------+
| 319992383.84 | 246.417910 |
+--------------+------------+
1 row in set (2.15 sec)
其他聚集函数的结果就不是FULL INDEX SCAN了。耗时2.15秒。对于小表的操作。mysql> select min(money),max(money) from t_group_david;
+------------+------------+
| min(money) | max(money) |
+------------+------------+
| -6.41 | 500.59 |
+------------+------------+
1 row in set (1.50 sec)
最大最小值完全是FULL TABLE SCAN,耗时1.50秒,不划算。以此看来。mysql> select sum(money),avg(money) from t_group_david;
+--------------+------------+
| sum(money) | avg(money) |
+--------------+------------+
| 319992383.84 | 246.417910 |
+--------------+------------+
1 row in set (1.68 sec)
取得这两个结果也是花了快2秒,快了一点。我们来看看这个小表的结构。mysql> desc t_group_david;
+-------------+------------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------------+------+-----+-------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| money | decimal(10,2) | NO | | | |
| user_name | varchar(20) | NO | MUL | | |
| create_time | timestamp | NO | | CURRENT_TIMESTAMP | |
+-------------+------------------+------+-----+-------------------+----------------+
4 rows in set (0.00 sec)
明显的user_name属性是多余的。那么就干掉它。mysql> alter table t_group_david drop user_name;
Query OK, 1298576 rows affected (7.58 sec)
Records: 1298576 Duplicates: 0 Warnings: 0
现在来重新对小表运行查询mysql> select min(money),max(money) from t_group_david;
+------------+------------+
| min(money) | max(money) |
+------------+------------+
| -6.41 | 500.59 |
+------------+------------+
1 row in set (0.00 sec)
此时是瞬间的。mysql> select sum(money),avg(money) from t_group_david;
+--------------+------------+
| sum(money) | avg(money) |
+--------------+------------+
| 319992383.84 | 246.417910 |
+--------------+------------+
1 row in set (0.94 sec)
这次算是控制在一秒以内了。mysql> Aborted
小总结一下:分出的小表的属性尽量越少越好。大胆的去干吧。
分享到:
相关推荐
MySQL分表及分表后插入sql语句,表为订单表,可以参考一下
本文将深入探讨基于Node.js实现的MySQL分表分库中间件,它在分布式集群环境中起到至关重要的作用。 首先,Node.js是一种流行的JavaScript运行环境,它允许开发人员使用JavaScript进行服务器端编程。Node.js的异步非...
MySQL 分表分库 Demo MySQL 分表分库是指将大型数据库表分割成多个小表,以提高数据库的性能和可扩展性。随着业务数据的增长,数据库表中的数据不断增加,如果不加以控制,数据库的性能将会下降,影响业务的发展。 ...
MySQL分表和分区最佳攻略 word版本,
MySQL分库分表是数据库架构设计中用于处理大规模数据量以及高并发请求的一种技术手段。通过将数据拆分到不同的数据库服务器中,能够有效降低单个数据库的负载,提高系统的扩展性和性能。Python作为一种流行的编程...
MySQL作为一款广泛使用的开源关系型数据库,面对海量数据时,分表策略是一种有效的优化手段。本文将详细讲解如何在MySQL中进行分表创建,以及相关的源码和工具应用。 首先,分表(Sharding)是数据库水平扩展的一种...
本篇文章将深入探讨"Python与MySQL分表分库实战"这一主题,帮助你理解如何有效地利用这两种技术来优化数据库性能和处理大数据。 首先,我们需要理解“分表分库”这一概念。随着数据量的增长,单一数据库可能会面临...
关于mysql的分表技术实现方法。以及分表设计, 及简单的代码实例。
常开发中我们经常会遇到大表的情况,所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大,导致...分表和表分区的目的就是减少数据库的负担,提高数据库的效率,通常点来讲就是提高表的增删改查效率。
Python后端运维工程师的可靠参考书,重点介绍如何优化mysql数据库性能。
MySQL提供了多种分表策略,如哈希分表、范围分表和列表分表,这些方法可以帮助我们有效地管理和优化数据库性能。 ### 1. 哈希分表 哈希分表是通过计算数据的哈希值来决定数据应存储在哪个子表中,以此达到均匀分布...
Mysql数据优化方案: 方案一:使用myisam进行水平分表优化 方案二:使用mysql分区优化 一:Myisam水平分区 1、创建水平分表 user_1: -- 创建水平分表 create table user_1( id varchar(50) PRIMARY key COMMENT '...
MySQL 分库分表查询工具——Shard 在大型的互联网应用中,数据库的性能瓶颈往往成为系统扩展性的关键因素。为了应对高并发、大数据量的挑战,MySQL 数据库的分库分表策略被广泛采用。分库是将数据分散到多个独立的...
当数据量达到一定规模,例如超过100万条记录,性能问题就会显现,此时就需要采取相应的优化策略,如分表或分区。本文主要讨论如何使用PHP操作MySQL数据库进行分表。 分表是一种常见的数据库扩展策略,它通过将一个...
"基于hibernate的mysql分表分库实例-mysql-cluster-hibernate.zip"这个压缩包文件提供了一个具体的解决方案,它涉及到Hibernate ORM框架与MySQL数据库集群的整合,旨在处理高并发、大数据量的业务场景。 **...
其中有每个命令的使用说明与注释。并增加了清理数据的方式。以及导入输入的注意事项
MySQL数据库之分库分表方案_ITPUB博客.mhtml MySQL数据库之分库分表方案_ITPUB博客.mhtml MySQL数据库之分库分表方案_ITPUB博客.mhtml