数据库单表的测试
基于这个问题的测试为什么MySQL单表不要超过2000w行?
测试过程:
1 | CREATE TABLE test( |
200w行表:
1 | mysql> describe table test; |
400w:
1 | mysql> describe table test; |
800w:
1 | mysql> describe table test; |
1600w:
1 | mysql> describe table test; |
3200w:
1 | mysql> describe table test; |
这个结果基本上都是线性的, 感觉数据量实在是太小了。
1 | mysql> show table status like 'test'\G |
换个方案( 从大佬那边伸手拿来的
1 | CREATE TABLE tt1( |
这次的话, 添加数据的时间实在是太久了, 记录一下中间结果的变化吧:
1 | MySQL [test]> select count(*) from tt1; |
对于MySQL的内存使用,在数据库启动后,不会立即将buffer pool对应的内存占用,而是随着使用逐步占用。
在5月19日看到您的实例有连接数达到1200,并持续了一段时间,内存随之下降。您可以通过查看 Innodb_buffer_pool_size 的值来确定 buffer pool 的最大值。
然后根据公式来计算预期的内存使用情况:
Maximum MySQL Memory Usage = innodb_buffer_pool_size + key_buffer_size + ((read_buffer_size + read_rnd_buffer_size + sort_buffer_size + join_buffer_size) X max_connections)我按照您的配置,创建了mysql 5.7.41 版本,实例类型为 db.m5.xlarge ,公式中的参数均为默认值,计算结果如下:
Maximum MySQL Memory Usage
= innodb_buffer_pool_size + key_buffer_size + ((read_buffer_size + read_rnd_buffer_size + sort_buffer_size + join_buffer_size) X max_connections)
= 11811160064 + 16777216 + (262144 + 524288 + 262144 + 262144 ) * 1200
= 13400801280 即 12.48GB总内存为 16 GB ,减去 12.48 GB,还剩下 3.52 GB。再除去一些SQL执行中消耗的内存以及操作系统等消耗的内存,目前指标上显示剩余1.5GB左右。
在5月19日连接数增加前,按300连接数算,上述公式计算结果为 11.38 GB,然而可用内存指标显示为 7 GB,相加起来是大于 16 GB 的。由此也能说明是 MySQL 并未直接将参数设置的所有可用内存都占用,而是随着使用逐步增加的。
当连接数增加后,MySQL真正使用了这部分内存(如buffer pool),不会主动释放。因此目前可用内存状况符合预期,如果您希望回收 MySQL 占用的内存,可以考虑重启数据库,但之后业务量较大时,还会重新占用这些内存。
Mysql80重置密码
1 | echo "skip-grant-tables" >> /etc/my.cnf |
MySQLVersion 8.0 修改密码策略:
1 | mysql -u wordpress -p -h mysql.liarlee.site |
如果添加了 skip-grant-tables 参数的话, 默认需要先flush priviledges; 然后才能更改密码, 否则的话会报错:
ERROR 1290 (HY000): The MySQL server is running with the –skip-grant-tables option so it cannot execute this statement
解决办法是 :
1 | mysql> alter user 'root'@'localhost' identified by '123123'; |


