在本实验中，你将学习 MySQL 的基础错误处理和日志记录技术。有效的错误管理对于构建健壮且易于维护的数据库应用程序至关重要，因为它能帮助你诊断问题、理解查询执行并确保数据完整性。
你将首先启用通用查询日志（general query log），以捕获发送到服务器的所有 SQL 语句，这是一个强大的调试和审计工具。接下来，你将在存储过程中使用 DECLARE HANDLER 来实现错误处理，从而优雅地管理意外错误。你还将学习如何使用 SIGNAL 语句创建和触发自定义错误条件，以强制执行业务规则。最后，你将检查 MySQL 错误日志（MySQL error log），其中包含有关服务器操作和关键问题的宝贵信息。
完成本实验后，你将对 MySQL 的错误处理和日志记录有扎实的基础，从而能够构建更可靠的数据库解决方案。
通用查询日志（general query log）会记录来自客户端的每一条 SQL 语句。它是调试和审计的宝贵工具，但应临时使用，因为它会影响性能并占用大量磁盘空间。在此步骤中，你将启用日志，生成一些活动，并查看日志文件。
首先，从你的桌面打开终端。
以 root 用户连接到 MySQL 服务器。在此实验环境中，你可以使用 sudo 在不输入密码的情况下连接。
sudo mysql -u root看到 mysql> 提示符后，全局启用通用查询日志。
SET GLOBAL general_log = 'ON';默认情况下，日志文件存储在 MySQL 数据目录中。为了方便访问，让我们将其位置更改为 /tmp 目录。
SET GLOBAL general_log_file = '/tmp/mysql_general.log';你可以通过运行以下命令来验证新位置：
SHOW VARIABLES LIKE 'general_log_file';输出应确认你刚刚设置的路径。
+------------------+-------------------------+
| Variable_name | Value |
+------------------+-------------------------+
| general_log_file | /tmp/mysql_general.log |
+------------------+-------------------------+
1 row in set (0.01 sec)现在，执行一些命令来生成日志条目。
CREATE DATABASE IF NOT EXISTS testdb;
USE testdb;
SELECT 'Logging this query' AS message;运行完这些命令后，退出 MySQL shell。
exit回到你的终端，查看日志文件的内容。
sudo cat /tmp/mysql_general.log你将看到你执行的命令，以及连接信息和时间戳。这证实了通用查询日志正在正常工作。
/usr/sbin/mariadbd, Version: 10.6.18-MariaDB-0ubuntu0.22.04.1 (Ubuntu 22.04). started with:
Tcp port: 3306 Unix socket: /run/mysqld/mysqld.sock
Time Id Command Argument
250728 14:12:46 33 Query SHOW VARIABLES LIKE 'general_log_file'
250728 14:12:50 33 Query CREATE DATABASE IF NOT EXISTS testdb
33 Query SELECT DATABASE()
33 Init DB testdb
33 Query show databases
33 Query show tables
33 Query SELECT 'Logging this query' AS message
250728 14:12:56 33 Quit最后，在完成后禁用日志是一个好习惯。你可以直接从终端进行操作。
sudo mysql -u root -e "SET GLOBAL general_log = 'OFF';"这可以确保日志不会继续增长并影响服务器性能。
存储过程可能因多种原因失败，例如尝试将重复数据插入主键列。使用错误处理程序可以让你捕获这些错误并优雅地响应，而不是让过程崩溃。在此步骤中，你将创建一个带有针对重复键错误的处理程序的存储过程。
首先，连接到 MySQL 服务器。
sudo mysql -u root如果 testdb 数据库尚不存在，请创建它并切换到该数据库。然后，创建一个 products 表。
CREATE DATABASE IF NOT EXISTS testdb;
USE testdb;
CREATE TABLE products (
id INT PRIMARY KEY,
name VARCHAR(255),
quantity INT
);现在，创建一个存储过程来插入新产品。此版本包含一个 DECLARE HANDLER，它可以捕获重复键错误（SQLSTATE 23000）并返回自定义消息。
DELIMITER 命令将语句终止符从 ; 更改为 //，这使得过程体内的分号能够被正确处理。
DELIMITER //
CREATE PROCEDURE insert_product(IN p_id INT, IN p_name VARCHAR(255))
BEGIN
-- 声明一个 EXIT HANDLER 来处理重复键错误
DECLARE EXIT HANDLER FOR SQLSTATE '23000'
BEGIN
SELECT 'Error: Product with this ID already exists.' AS message;
END;
-- 尝试插入产品
INSERT INTO products (id, name, quantity) VALUES (p_id, p_name, 0);
SELECT 'Product inserted successfully.' AS message;
END //
DELIMITER ;让我们测试一下这个过程。首先，插入一个新产品。
CALL insert_product(1, 'Laptop');这应该会成功并返回成功消息。
+--------------------------------+
| message |
+--------------------------------+
| Product inserted successfully. |
+--------------------------------+
1 row in set (0.00 sec)现在，尝试插入具有相同 id 的产品。
CALL insert_product(1, 'Desktop');这次，错误处理程序被触发，你收到的是自定义错误消息，而不是通用的 MySQL 错误。
+-----------------------------------------------+
| message |
+-----------------------------------------------+
| Error: Product with this ID already exists. |
+-----------------------------------------------+
1 row in set (0.00 sec)这演示了错误处理程序如何使你的存储过程更加用户友好和健壮。
处理程序可以捕获错误，而 SIGNAL 语句则允许你抛出错误。这对于强制执行标准数据库约束未涵盖的业务规则非常有用。在此步骤中，你将创建一个使用 SIGNAL 来防止输入产品数量为负值的过程。
你应该仍然在 MySQL shell 中。如果不在，请重新连接。
sudo mysql -u root确保你正在使用 testdb 数据库。
USE testdb;现在，创建一个存储过程来更新产品的数量。该过程将检查新数量是否为负数。如果是，它将使用 SIGNAL 抛出一个自定义错误。
DELIMITER //
CREATE PROCEDURE update_quantity(IN p_id INT, IN p_quantity INT)
BEGIN
-- 检查数量是否为负数
IF p_quantity < 0 THEN
-- 抛出自定义错误
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'Error: Quantity cannot be negative.';
END IF;
-- 如果检查通过，则更新数量
UPDATE products SET quantity = p_quantity WHERE id = p_id;
SELECT 'Quantity updated successfully.' AS message;
END //
DELIMITER ;在这里，SQLSTATE '45000' 是用户定义错误的通用状态码。MESSAGE_TEXT 设置客户端将看到的错误消息。
让我们测试一下这个过程。首先，尝试对你在上一步创建的“Laptop”产品进行有效更新。
CALL update_quantity(1, 50);这应该会成功执行。
+--------------------------------+
| message |
+--------------------------------+
| Quantity updated successfully. |
+--------------------------------+
1 row in set (0.00 sec)现在，尝试使用负数更新数量。
CALL update_quantity(1, -10);此调用将触发 SIGNAL 语句，并且过程将以你的自定义错误终止。
ERROR 1644 (45000): Error: Quantity cannot be negative.这证实了你可以使用 SIGNAL 在数据库中成功强制执行自定义业务逻辑。
MySQL 错误日志是诊断服务器级别问题的首要资源。它记录了服务器的启动和关闭事件、关键错误和警告。了解如何查找和阅读此日志是任何数据库管理员的一项基本技能。
你应该仍然在 MySQL shell 中。首先，通过查询 log_error 变量来查找错误日志文件的位置。
SHOW VARIABLES LIKE 'log_error';在此 LabEx VM 环境（Docker 容器）中，你可能会看到错误日志路径的值为空：
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_error | |
+---------------+-------+
1 row in set (0.001 sec)注意: 在像此 LabEx VM 这样的容器化环境中，MySQL/MariaDB 的错误日志记录通常配置为输出到容器的标准错误流，而不是传统的日志文件。这是 Docker 容器中遵循“12-factor app”方法论的一种常见做法。
让我们通过尝试访问一个不存在的数据库来演示错误处理：
USE non_existent_database;此命令在客户端会失败，正如预期的那样。
ERROR 1049 (42000): Unknown database 'non_existent_database'现在，退出 MySQL shell 返回到你的终端。
exit在具有传统 MySQL 安装的生产环境中，你通常会在 Ubuntu 系统上找到位于 /var/log/mysql/error.log 的错误日志。你可以检查传统日志文件是否存在：
sudo ls -la /var/log/mysql/ 2> /dev/null || echo "MySQL log directory not found (normal in containerized environments)"理解不同环境中的错误日志记录：
/var/log/mysql/error.log 的文件中。在生产环境中，你将定期使用以下命令来查看错误日志：
sudo tail -f /var/log/mysql/error.log （实时跟踪日志）sudo grep -i error /var/log/mysql/error.log （搜索特定错误）这种做法对于监控服务器健康状况和排查诸如启动失败、表损坏或权限问题等故障至关重要。
在此实验中，你学习了 MySQL 中错误处理和日志记录的基础技术。你首先启用了通用查询日志并进行了配置，以跟踪 SQL 语句，这是调试的关键技能。然后，你使用 DECLARE HANDLER 在存储过程中实现了健壮的错误处理，使其能够优雅地管理特定错误。
此外，你还学习了如何使用 SIGNAL 语句抛出自定义错误来强制执行业务规则，从而提供清晰具体的反馈。最后，你探索了 MySQL 错误日志记录的概念，包括传统安装与 Docker 容器等容器化环境之间错误日志记录的差异。
你了解到，虽然传统的 MySQL 安装将错误日志写入文件（如 /var/log/mysql/error.log），但容器化环境通常会将错误输出重定向到 stdout/stderr，以便更好地与容器编排平台集成。在处理现代部署环境时，理解这一点至关重要。
通过掌握这些技术，你现在能够更好地构建可靠的数据库应用程序，有效地解决问题，并确保在不同的部署场景下 MySQL 数据库的完整性。
