Linux服务器上查询数据库日志，核心思路是先明确数据库类型、再定位日志文件位置、最后用正确的命令读取和分析，不同数据库的日志机制差异很大，但都遵循“找配置、看文件、按时间或级别过滤”这一通用路径。
Linux下数据库日志存放在哪？先定位，再查询
很多人在服务器上排查问题时，第一反应是去/var/log目录找数据库日志，但这往往扑个空，数据库日志和系统日志不同，MySQL、PostgreSQL、MongoDB、Redis的日志位置和查看方式各有各的逻辑，如果连日志文件在哪都没搞清楚,后面的排查就是瞎忙活。
以最常见的MySQL为例，日志位置通常由配置文件my.cnf或my.ini中的log_error、general_log_file、slow_query_log_file参数决定,你可以用以下命令快速确认：
mysql -u root -p -e "SHOW VARIABLES LIKE 'log%';"
这条命令会列出所有日志相关的变量，包括错误日志路径、通用查询日志开关、慢查询日志开关等，一般错误日志默认在/var/log/mysql/error.log，慢查询日志在/var/log/mysql/mysql-slow.log。
PostgreSQL的日志配置在postgresql.conf文件中，核心参数是logging_collector（是否开启日志收集）、log_directory（日志目录）、log_filename（日志文件名格式），默认情况下，日志会写在数据目录下的log文件夹里,找到数据目录：
ps aux | grep postgres
输出结果里能看到类似-D /var/lib/pgsql/data的参数，日志就在那下面的log目录中。
MongoDB的日志路径由启动参数--logpath或配置文件mongod.conf中的systemLog.path决定，Redis则相对简单，日志通过logfile配置项指定，如果没配置，日志会直接输出到标准输出（stdout）,也就是你启动Redis的那个终端窗口。
小结：查询数据库日志的第一步，永远是确认数据库类型和日志文件的实际位置，而不是凭经验猜测。
MySQL日志查询实操：错误日志、慢查询、二进制日志
MySQL是Linux服务器上部署最广泛的数据库，围绕“Linux服务器上mysql数据库日志怎么查询”这个问题，实际操作可以拆成三种场景,分别对应三类日志。
错误日志查询：最先要看的地方
错误日志记录MySQL启动、运行、停止过程中的异常信息，是排查故障的第一站，除了用SHOW VARIABLES查看路径,还可以直接通过SQL查询当前错误日志的位置：
SELECT @@log_error;
拿到路径后,用标准Linux命令查看最新内容：
# 查看最后50行 tail -n 50 /var/log/mysql/error.log # 实时跟踪日志输出 tail -f /var/log/mysql/error.log # 按关键字搜索 grep "ERROR" /var/log/mysql/error.log | tail -n 20
场景示例：某天凌晨网站突然报数据库连接超时，你登录服务器后，第一件事就是执行tail -f /var/log/mysql/error.log，看到日志里刷出一片Too many connections，这就说明连接数打满了，接着查max_connections配置和当前连接数,问题就能快速锁定。
慢查询日志：定位性能瓶颈的关键
慢查询日志记录执行时间超过设定阈值的SQL语句，是优化的核心依据,查询当前配置：
SHOW VARIABLES LIKE 'slow_query_log'; -- 是否开启，ON为开启 SHOW VARIABLES LIKE 'long_query_time'; -- 阈值，单位秒 SHOW VARIABLES LIKE 'slow_query_log_file'; -- 日志文件路径
如果慢查询日志没开启，临时开启（重启后失效）：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; -- 超过1秒的SQL记录
查看慢查询日志的推荐方式，是用mysqldumpslow工具汇总分析，而不是直接cat整个文件，对于文件较大的情况，直接cat会产生大量无意义输出，等于大海捞针。正确做法是先用工具做个统计：
# 统计最慢的10条SQL mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log # 按平均耗时排序 mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log
mysqldumpslow输出的结果会去重同类的SQL（参数值不同用N代替）,方便你快速识别哪些SQL模板最需要优化。
通用查询日志与二进制日志
通用查询日志（general log）记录所有客户端请求，包括每条SQL和连接断开事件。默认关闭，因为日志量极大，生产环境开启会拖累性能，排查问题时可以临时开启,定位到具体问题就立刻关闭：
SET GLOBAL general_log = 'ON'; -- 定位日志位置后tail查看 SET GLOBAL general_log = 'OFF'; -- 用完立刻关
二进制日志（binlog）主要用于数据恢复和主从复制，它记录的是数据变更操作，不是查询,查看binlog的SQL：
SHOW BINARY LOGS; -- 列出所有binlog文件 SHOW MASTER STATUS; -- 当前正在写的binlog
用mysqlbinlog工具读取内容：
mysqlbinlog /var/lib/mysql/mysql-bin.000023 | grep "DELETE FROM"
PostgreSQL与MongoDB日志查询：各有一套逻辑
说完了MySQL，如果把范围扩大到“Linux服务器数据库日志查询”，PostgreSQL和MongoDB也需要单独掌握,它们的日志操作逻辑并不通用。
PostgreSQL日志：journald与文件双通道
PostgreSQL日志查询有个特殊之处取决于你安装方式和系统配置，日志可能被systemd的journald捕获,而不一定以文件形式存储在数据目录下。
先看日志是否输出到journald：
journalctl -u postgresql --since "1 hour ago"
这条命令查询最近一小时内PostgreSQL服务输出的全部日志，如果明确要查文件日志，修改postgresql.conf中的logging_collector = on并重启服务，日志就会写入log_directory目录。
实际排查中,更常用的过滤方式是按错误级别和关键字：
# 查看最近1000行中错误级别的日志 grep "FATAL" $(find /var/lib/pgsql -name ".log" -mtime -1) | tail -n 20 # 按时间范围过滤 journalctl -u postgresql --since "2026-01-01 00:00" --until "2026-01-01 06:00"
PostgreSQL日志中几个关键级别：FATAL（连接中断、进程崩溃）、ERROR（SQL语句报错）、WARNING（潜在问题），排查问题时优先看FATAL级日志,定位问题效率最高。
MongoDB日志：JSON格式与verbose级别
MongoDB日志默认是JSON格式，每行一个条带时间戳，查询的关键在于善用grep和jq（如果是JSON格式输出）。
先确认日志路径：
mongod --print-options | grep logpath
# 或者连接mongo shell
mongo --eval "db.adminCommand({getCmdLineOpts:1}).parsed.systemLog.path"
# 查看最后100行 tail -n 100 /var/log/mongodb/mongod.log # 搜索特定关键字 grep "connection accepted" /var/log/mongodb/mongod.log | tail # 搜索错误，排除连接相关噪音 grep -E "ERROR|FATAL" /var/log/mongodb/mongod.log | grep -v "connection" | tail -n 30
MongoDB日志的verbosity（日志详细级别）用--verbose参数或db.setLogLevel()设置，生产环境默认级别一般够用，排查慢操作时可以把级别调高到db.setLogLevel(1)，查到问题后恢复默认。
日志文件越来越大？学会按时间排查和备份
日志查询不光是定位故障文件，日常维护中日志切割、归档、定期清理同样值得投入精力做对，如果日志把磁盘占满,数据库可能直接宕机。
行业共识认为，处理日志文件增长的标准方案是logrotate，Linux发行版自带logrotate，MySQL等数据库安装后一般会自动配置日志轮转规则,检查方式：
cat /etc/logrotate.d/mysql
典型的MySQL日志轮转配置包含：
daily：按天轮转rotate 7：保留最近7份compress：压缩归档旧日志
如果你自己配置轮转，一个实用的建议是：设置create 640 mysql mysql参数，确保日志轮转后新日志文件的属主和权限正确,否则MySQL可能因为无法写入新日志而重启失败。
场景示例：某次你的监控平台发来告警，/var/lib/mysql分区使用率超过90%，登录服务器后发现就是mysql-slow.log
涨到了几十GB，这时候先别急着删，确认慢查询日志是否还有价值：如果近期在做SQL优化，先cp一份再清理；如果只是囤积了几个月的数据,直接清空并让日志轮转继续接管后续。
Linux服务器数据库日志查询速查表
| 数据库 | 日志类型 | 默认位置 | 查看命令 |
|---|---|---|---|
| MySQL | 错误日志 | /var/log/mysql/error.log |
tail -f |
| MySQL | 慢查询日志 | /var/log/mysql/mysql-slow.log |
mysqldumpslow |
| PostgreSQL | 服务日志 | 数据目录log/或journald |
journalctl -u postgresql |
| MongoDB | 全量日志 | /var/log/mongodb/mongod.log |
grep -E "ERROR" |
快速定位问题日志的通用步骤
- 明确数据库类型和版本，不同版本可能有配置差异
- 登录服务器后先看运行中进程的启动参数
ps aux | grep，确认数据目录或配置路径 - 全局搜索日志文件，例如
find / -name ".log" -mtime -1限定最近修改过的日志 - 不要直接乱翻整个目录，先用
tail -n 100判断是否相关 - 结合具体报错时间点和关键字做过滤，而不是通读整个文件
关于Linux服务器数据库日志查询，你可能会问
Q：MySQL慢查询日志开启了但文件里没有内容，是什么原因？
A：long_query_time的单位是秒，默认值10秒意味着执行超过10秒的SQL才会被记录，用开启状态下的SQL查询检查当前会话变量，注意全局变量刚修改时，当前会话需要重新连接才能生效，另一个常见原因是慢查询日志路径和当前系统实际写入路径不一致，检查配置时确认没有改动slow_query_log_file。
Q：PostgreSQL日志中大量shutdown和startup记录是否正常？
A：这通常对应数据库重启或崩溃恢复事件，如果这类记录频繁出现且伴随FATAL错误，说明数据库存在不稳定因素，仅出现一次且时间点与你的重启操作吻合，属于正常现象，可结合uptime和last reboot核对服务器重启时间与数据库日志时间是否同步。
Q：日志文件被logrotate轮转后，使用tail -f看不到新日志怎么办？
A：轮转后的新日志文件可能以.1、.2等后缀保存在同一目录。tail -f跟随的是文件描述符，如果服务仍在向旧文件写入，会显示轮转前的旧数据，用ls -lt ++{1..5}查看日志目录下最新生成的文件，确认实际文件名后再跟踪，数据库服务通常需要重启或发送信号才能重新打开新日志文件，检查轮转配置中的postrotate执行状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e5%a6%82%e4%bd%95%e6%9f%a5%e8%af%a2linux%e6%9c%8d%e5%8a%a1%e5%99%a8%e6%95%b0%e6%8d%ae%e5%ba%93%e6%97%a5%e5%bf%97%ef%bc%9f%e6%95%b0%e6%8d%ae%e5%ba%93%e6%97%a5%e5%bf%97%e5%88%86%e6%9e%90%e6%8a%80/
