MySQL 在崩溃恢复时,会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性,如果 MySQL 中包含了大量表,这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关,表总数越大,崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间,像这里开发库的 HDD IOPS 较低,因此面对大量的表空间,校验速度就非常缓慢。另外一个发现,MySQL 8 下正常启用时居然也会进行表空间校验,而故障恢复时则会额外再进行一次表空间校验,等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性,即表数量超过 5W 时,会启用多线程扫描,加快表空间校验过程。
成都创新互联公司是一家专注于网站制作、网站建设与策划设计,梧州网站建设哪家好?成都创新互联公司做网站,专注于网站建设十载,网设计领域的专业建站公司;建站业务涵盖:梧州等地区。梧州做网站价格咨询:18982081108
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛?查阅了资料,方法主要有两种:
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ,那么 validate = false,即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1,也就是强制恢复跳过坏页,就可以跳过校验,然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程,快速启动 MySQL,个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了,只需要打开一个 ibdata 文件即可,大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后,感觉共享表空间在很多业务环境下,反而更有优势。
临时冒出另外一种解决想法,即用 GDB 调试崩溃恢复,通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程,然后让 MySQL 正常关闭,重新启动就可以正常启动了。但是实际测试发现,如果以 debug 模式运行,确实可以临时修改 validate 变量,跳过表空间验证过程,但是 debug 模式下代码运行效率大打折扣,反而耗时更长。而以非 debug 模式运行,则无法修改 validate 变量,想法破灭。
执行顺序:
适用结构相同的表联结成一张大表
内连接:返回两个表共同的行
左连接:以表 1 为基础,匹配表 2 的相同行
右连接:以表 2 为基础,匹配表 1 的相同行
全连接:返回全部数据,可以理解为左连接和右连接的结合
mysql 没有全连接
常用于组内排序,具体写法如下
窗口函数可以用 rank 相关函数或者聚合函数
当前日期+时间(date + time)函数:now()
当前时间戳函数:current_timestamp()
日期或时间转换为字符串 函数:date_format(date,format), time_format(time,format)
lower(str):将字符串参数值转换为全小写字母后返回
upper(str):将字符串参数值转换为全大写字母后返回
concat(str1, str2,...):将多个字符串参数首尾相连后返回
concat_ws(separator,str1,str2,...):将多个字符串参数以给定的分隔符 separator 首尾相连后返回
substr(str,pos):截取从 pos 位置开始到最后的所有 str 字符串
substr(str, pos, len):截取 str 字符串,从 pos 位置开始的 len 个字符
length(str):返回字符串的存储长度
char_length(str):返回字符串中的字符个数
format(X,D,locale):以格式 ‘#,###,###.##’ 格式化数字 X,D 指定小数位数,locale 指定国家语言(默认的 locale 为 en_US)
left(str, len):返回最左边的len长度的子串
right(str, len):返回最右边的len长度的子串
ltrim(str),rtrim(str):去掉字符串的左边或右边的空格
repeat(str, count):将字符串 str 重复 count 次后返回
reverse(str):将字符串 str 反转后返回
通俗易懂的学会:SQL窗口函数
mysql format时间格式化说明
MySQL常用字符串函数
你先要学习一下,Python的MySQL接口
通常就那么几个
pymysql
纯Python实现的,特性先进一些
只要# pip install pymysql 就可以了
mysql-connector-python
这个是MYSQL官方提供的
MySQLdb
这个是C语言实现的, 相对比较老旧. 但是网上例子却最多
在CentOS下用yum或pip安装都可以
这三个库我都用过, 基上使用方法上大同小异, 也基本上都满足要求.
做简单聚类分析,应该直接用
Scipy中的聚类包进行聚类分析就行了
scipy.cluster
要是复杂的分析估计就要用机器学习的库了
比如利用sklearn库中的cluster.Kmeans
总这用这个要选学习一下两个非常重要的基础库
Numpy是数据矩阵
Matplotlib是用来可视化
但是这两个都是工业级的库, 每个都是一本书.
一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句\x0d\x0a\x0d\x0a1,slow_query_log\x0d\x0a这个参数设置为ON,可以捕获执行时间超过一定数值的SQL语句。\x0d\x0a\x0d\x0a2,long_query_time\x0d\x0a当SQL语句执行时间超过此数值时,就会被记录到日志中,建议设置为1或者更短。\x0d\x0a\x0d\x0a3,slow_query_log_file\x0d\x0a记录日志的文件名。\x0d\x0a\x0d\x0a4,log_queries_not_using_indexes\x0d\x0a这个参数设置为ON,可以捕获到所有未使用索引的SQL语句,尽管这个SQL语句有可能执行得挺快。\x0d\x0a\x0d\x0a二、检测mysql中sql语句的效率的方法\x0d\x0a\x0d\x0a1、通过查询日志\x0d\x0a(1)、Windows下开启MySQL慢查询\x0d\x0aMySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上\x0d\x0a代码如下\x0d\x0alog-slow-queries = F:/MySQL/log/mysqlslowquery。log\x0d\x0along_query_time = 2\x0d\x0a\x0d\x0a(2)、Linux下启用MySQL慢查询\x0d\x0aMySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上\x0d\x0a代码如下\x0d\x0alog-slow-queries=/data/mysqldata/slowquery。log\x0d\x0along_query_time=2\x0d\x0a说明\x0d\x0alog-slow-queries = F:/MySQL/log/mysqlslowquery。\x0d\x0a为慢查询日志存放的位置,一般这个目录要有MySQL的运行帐号的可写权限,一般都将这个目录设置为MySQL的数据存放目录;\x0d\x0along_query_time=2中的2表示查询超过两秒才记录;\x0d\x0a\x0d\x0a2.show processlist 命令\x0d\x0a\x0d\x0aSHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。\x0d\x0a各列的含义和用途:\x0d\x0aID列\x0d\x0a一个标识,你要kill一个语句的时候很有用,用命令杀掉此查询 /*/mysqladmin kill 进程号。\x0d\x0auser列\x0d\x0a显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。\x0d\x0ahost列\x0d\x0a显示这个语句是从哪个ip的哪个端口上发出的。用于追踪出问题语句的用户。\x0d\x0adb列\x0d\x0a显示这个进程目前连接的是哪个数据库。\x0d\x0acommand列\x0d\x0a显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。\x0d\x0atime列\x0d\x0a此这个状态持续的时间,单位是秒。\x0d\x0astate列\x0d\x0a显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个 sql语句,以查询为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成\x0d\x0ainfo列\x0d\x0a显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。\x0d\x0a\x0d\x0a这个命令中最关键的就是state列,mysql列出的状态主要有以下几种:\x0d\x0aChecking table\x0d\x0a 正在检查数据表(这是自动的)。\x0d\x0aClosing tables\x0d\x0a 正在将表中修改的数据刷新到磁盘中,同时正在关闭已经用完的表。这是一个很快的操作,如果不是这样的话,就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。\x0d\x0aConnect Out\x0d\x0a 复制从服务器正在连接主服务器。\x0d\x0a\x0d\x0aCopying to tmp table on disk\x0d\x0a 由于临时结果集大于tmp_table_size,正在将临时表从内存存储转为磁盘存储以此节省内存。\x0d\x0aCreating tmp table\x0d\x0a 正在创建临时表以存放部分查询结果。\x0d\x0adeleting from main table\x0d\x0a 服务器正在执行多表删除中的第一部分,刚删除第一个表。\x0d\x0adeleting from reference tables\x0d\x0a 服务器正在执行多表删除中的第二部分,正在删除其他表的记录。\x0d\x0a\x0d\x0aFlushing tables\x0d\x0a 正在执行FLUSH TABLES,等待其他线程关闭数据表。\x0d\x0aKilled\x0d\x0a 发送了一个kill请求给某线程,那么这个线程将会检查kill标志位,同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位,不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了,那么kill请求会在锁释放时马上生效。\x0d\x0aLocked\x0d\x0a 被其他查询锁住了。\x0d\x0aSending data\x0d\x0a 正在处理SELECT查询的记录,同时正在把结果发送给客户端。\x0d\x0a\x0d\x0aSorting for group\x0d\x0a 正在为GROUP BY做排序。\x0d\x0a Sorting for order\x0d\x0a 正在为ORDER BY做排序。\x0d\x0aOpening tables\x0d\x0a 这个过程应该会很快,除非受到其他因素的干扰。例如,在执ALTER TABLE或LOCK TABLE语句行完以前,数据表无法被其他线程打开。正尝试打开一个表。\x0d\x0aRemoving duplicates\x0d\x0a 正在执行一个SELECT DISTINCT方式的查询,但是MySQL无法在前一个阶段优化掉那些重复的记录。因此,MySQL需要再次去掉重复的记录,然后再把结果发送给客户端。\x0d\x0a\x0d\x0aReopen table\x0d\x0a 获得了对一个表的锁,但是必须在表结构修改之后才能获得这个锁。已经释放锁,关闭数据表,正尝试重新打开数据表。\x0d\x0aRepair by sorting\x0d\x0a 修复指令正在排序以创建索引。\x0d\x0aRepair with keycache\x0d\x0a 修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。\x0d\x0aSearching rows for update\x0d\x0a 正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。\x0d\x0aSleeping\x0d\x0a 正在等待客户端发送新请求.\x0d\x0a\x0d\x0aSystem lock\x0d\x0a 正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表,那么可以通过增加--skip-external-locking参数来禁止外部系统锁。\x0d\x0aUpgrading lock\x0d\x0a INSERT DELAYED正在尝试取得一个锁表以插入新记录。\x0d\x0aUpdating\x0d\x0a 正在搜索匹配的记录,并且修改它们。\x0d\x0a\x0d\x0aUser Lock\x0d\x0a 正在等待GET_LOCK()。\x0d\x0aWaiting for tables\x0d\x0a 该线程得到通知,数据表结构已经被修改了,需要重新打开数据表以取得新的结构。然后,为了能的重新打开数据表,必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。\x0d\x0awaiting for handler insert\x0d\x0a INSERT DELAYED已经处理完了所有待处理的插入操作,正在等待新的请求。\x0d\x0a 大部分状态对应很快的操作,只要有一个线程保持同一个状态好几秒钟,那么可能是有问题发生了,需要检查一下。\x0d\x0a 还有其他的状态没在上面中列出来,不过它们大部分只是在查看服务器是否有存在错误是才用得着。\x0d\x0a\x0d\x0a例如如图:\x0d\x0a\x0d\x0a3、explain来了解SQL执行的状态\x0d\x0aexplain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。\x0d\x0a使用方法,在select语句前加上explain就可以了:\x0d\x0a例如:\x0d\x0aexplain select surname,first_name form a,b where a.id=b.id\x0d\x0a结果如图\x0d\x0a\x0d\x0aEXPLAIN列的解释\x0d\x0atable\x0d\x0a显示这一行的数据是关于哪张表的\x0d\x0atype\x0d\x0a这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL\x0d\x0apossible_keys\x0d\x0a显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句\x0d\x0akey\x0d\x0a实际使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL会选择优化不足的索引。这种情况下,可以在SELECT语句 中使用USE INDEX(indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引\x0d\x0akey_len\x0d\x0a使用的索引的长度。在不损失精确性的情况下,长度越短越好\x0d\x0aref\x0d\x0a显示索引的哪一列被使用了,如果可能的话,是一个常数\x0d\x0arows\x0d\x0aMYSQL认为必须检查的用来返回请求数据的行数\x0d\x0aExtra\x0d\x0a关于MYSQL如何解析查询的额外信息。将在表4.3中讨论,但这里可以看到的坏的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,结果是检索会很慢\x0d\x0a\x0d\x0aextra列返回的描述的意义\x0d\x0aDistinct\x0d\x0a一旦MYSQL找到了与行相联合匹配的行,就不再搜索了\x0d\x0aNot exists\x0d\x0aMYSQL优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,就不再搜索了\x0d\x0aRange checked for each Record(index map:#)\x0d\x0a没有找到理想的索引,因此对于从前面表中来的每一个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一\x0d\x0aUsing filesort\x0d\x0a看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行\x0d\x0aUsing index\x0d\x0a列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候\x0d\x0aUsing temporary\x0d\x0a看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上\x0d\x0aWhere used\x0d\x0a使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index,这就会发生,或者是查询有问题不同连接类型的解释(按照效率高低的顺序排序)\x0d\x0aconst\x0d\x0a表中的一个记录的最大值能够匹配这个查询(索引可以是主键或惟一索引)。因为只有一行,这个值实际就是常数,因为MYSQL先读这个值然后把它当做常数来对待\x0d\x0aeq_ref\x0d\x0a在连接中,MYSQL在查询时,从前面的表中,对每一个记录的联合都从表中读取一个记录,它在查询使用了索引为主键或惟一键的全部时使用\x0d\x0aref\x0d\x0a这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好\x0d\x0arange\x0d\x0a这个连接类型使用索引返回一个范围中的行,比如使用或
回答于 2022-11-16
第一优化你的sql和索引;
第二加缓存,memcached,redis;
第三以上都做了后,还是慢,就做主从复制或主主复制,读写分离,可以在应用层做,效率高,也可以用三方工具,第三方工具推荐360的atlas,其它的要么效率不高,要么没人维护;
第四如果以上都做了还是慢,不要想着去做切分,mysql自带分区表,先试试这个,对你的应用是透明的,无需更改代码,但是sql语句是需要针对分区表做优化的,sql条件中要带上分区条件的列,从而使查询定位到少量的分区上,否则就会扫描全部分区,另外分区表还有一些坑,在这里就不多说了;
第五如果以上都做了,那就先做垂直拆分,其实就是根据你模块的耦合度,将一个大的系统分为多个小的系统,也就是分布式系统;
第六才是水平切分,针对数据量大的表,这一步最麻烦,最能考验技术水平,要选择一个合理的sharding key,为了有好的查询效率,表结构也要改动,做一定的冗余,应用也要改,sql中尽量带sharding key,将数据定位到限定的表上去查,而不是扫描全部的表;
mysql数据库一般都是按照这个步骤去演化的,成本也是由低到高;