mysql查询30w条报错_MySQL慢查询方法学习

以下的文章主要介绍的是MySQL慢查询分析方法,前一段日子,我曾经设置了一次记录在MySQL数据库中对慢于1秒钟的SQL语句进行查询。想起来有几个十分设置的方法,有几个参数的名称死活回忆不起来了,于是重新整理一下,自己做个笔记。

对于排查问题找出性能瓶颈来说,最容易发现并解决的问题就是MySQL慢查询以及没有得用索引的查询。

OK,开始找出MySQL中执行起来不“爽”的SQL语句吧。

MySQL慢查询分析方法一:

这个方法我正在用,呵呵,比较喜欢这种即时性的。

MySQL5.0以上的版本可以支持将执行比较慢的SQL语句记录下来。

1. MySQL> show variables like 'long%';

注:这个long_query_time是用来定义慢于多少秒的才算“慢查询”

1. +-----------------+-----------+

2. | Variable_name | Value |

3. +-----------------+-----------+

4. | long_query_time | 10.000000 |

5. +-----------------+-----------+

6. 1 row in set (0.00 sec)

7. MySQL> set long_query_time=1;

注: 我设置了1, 也就是执行时间超过1秒的都算慢查询。

1. Query OK, 0 rows affected (0.00 sec)

2. MySQL> show variables like 'slow%';

3. +---------------------+---------------+

4. | Variable_name | Value |

5. +---------------------+---------------+

6. | slow_launch_time | 2 |

7. | slow_query_log | ON |

注:是否打开日志记录

1. | slow_query_log_file | /tmp/slow.log |

注: 设置到什么位置

1. +---------------------+---------------+

2. 3 rows in set (0.00 sec)

3. MySQL> set global slow_query_log='ON'

注:打开日志记录

一旦slow_query_log变量被设置为ON,MySQL会立即开始记录。

/etc/my.cnf 里面可以设置上面MySQL全局变量的初始值。

1. long_query_time=1

2. slow_query_log_file=/tmp/slow.log

MySQL慢查询分析方法二:

MySQLdumpslow命令

1. /path/MySQLdumpslow -s c -t 10 /tmp/slow-log

这会输出记录次数最多的10条SQL语句,其中:

-s, 是表示按照何种方式排序,c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序,ac、at、al、ar,表示相应的倒叙;

-t, 是top n的意思,即为返回前面多少条的数据;

-g, 后边可以写一个正则匹配模式,大小写不敏感的;

比如

1. /path/MySQLdumpslow -s r -t 10 /tmp/slow-log

得到返回记录集最多的10个查询。

1. /path/MySQLdumpslow -s t -t 10 -g “left join” /tmp/slow-log

得到按照时间排序的前10条里面含有左连接的查询语句。

以上的相关内容就是对MySQL慢查询分析的介绍,望你能有所收获。

### MySQL 中与 PID 文件相关的错误原因及解决方案 当遇到 `The server quit without updating PID file` 错误时,通常表明 MySQL 服务未能成功启动并更新其进程 ID (PID) 文件。以下是可能的原因及其对应的解决方案: #### 原因一:权限不足 如果 MySQL 进程无法访问或写入指定的 PID 文件路径,则可能导致此错误。可以通过检查文件系统的权限来验证这一点。 - **解决方法** 确保 MySQL 用户拥有对数据目录以及 PID 文件所在路径的读写权限。可以运行以下命令调整权限: ```bash sudo chown -R mysql:mysql /usr/local/mysql/data/ sudo chmod -R 755 /usr/local/mysql/data/ ``` 此外,确认 `/etc/my.cnf` 配置文件中的 `[mysqld]` 节是否存在正确的 `pid-file` 设置[^1]。 --- #### 原因二:遗留的旧 PID 文件 有时,在异常关闭 MySQL 或服务器崩溃后,可能会留下未清理的 PID 文件。这会误导新实例尝试加载已存在的 PID 并失败。 - **解决方法** 手动删除残留的 PID 文件后再重新启动 MySQL 服务: ```bash sudo rm -f /usr/local/mysql/data/localhost.localdomain.pid sudo systemctl restart mysqld ``` 通过查看日志文件进一步排查是否有其他潜在问题[^2]: ```bash sudo tail -n 50 /var/log/mysqld.log ``` --- #### 原因三:表结构损坏 某些情况下,MySQL 的核心授权表(如 `proxies_priv` 表)缺失或损坏也会引发类似的错误消息。 - **解决方法** 修复数据库元数据和系统表。执行如下操作以重建必要的内部表: ```sql mysql_upgrade --force ``` 或者直接初始化一个新的数据目录(注意备份现有数据以防丢失): ```bash sudo mkdir -p /new/datadir/path sudo rsync -avP /old/datadir/* /new/datadir/ sudo mysql_install_db --datadir=/new/datadir/path --user=mysql ``` 同时需关注具体报错提示是否涉及特定对象不存在的情况[^3]。 --- #### 总结代码片段 综合以上分析过程可编写一段脚本用于自动化诊断此类问题: ```bash #!/bin/bash LOG_FILE="/var/log/mysqld.log" PID_PATH="/usr/local/mysql/data/" CONF_FILE="/etc/my.cnf" echo "Checking permissions..." if [[ ! -w "$PID_PATH" || $(stat -c '%U:%G' $PID_PATH) != "mysql:mysql" ]]; then echo "Fixing ownership and mode of ${PID_PATH} ..." sudo chown -R mysql:mysql "${PID_PATH}" sudo chmod -R 750 "${PID_PATH}" fi echo "Removing stale PID files if any..." find "${PID_PATH}" -name "*.pid" | while read line; do sudo rm -fv "$line" done echo "Restarting service..." sudo systemctl restart mysqld && sleep 5 if grep -qiE "(error|fatal)" "${LOG_FILE}"; then echo "[WARN] Errors detected in log:" tail -n 10 "${LOG_FILE}" else echo "[INFO] Service started successfully." fi ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值