简介这是一套面向数据库初学者与Web开发者的MySQL与SQL系统学习资料覆盖从环境搭建、基础语法到高级特性和性能优化的完整知识链特别适合零基础入门及备考数据库相关认证的学习者。资源包共41个文件含20份PDF教程如《MySQL数据类型精讲》《事务处理》《索引与查询优化》等、19个配套SQL脚本按章节组织涵盖多表查询、触发器、存储过程等实操练习以及2份Markdown说明文档总大小21.88MB结构清晰、学练结合。已有220人下载学习体现了较强的实际应用认可度。学习者可获得体系化的笔记脉络、即用型SQL示例、典型场景下的建表与查询方案以及Web开发中MySQL集成的关键实践要点助力快速构建扎实的数据库操作与设计能力。1. 这不是又一份“MySQL入门PDF”它是一套能让你在Linux服务器上亲手启停服务、用mysql命令连进黑屏、写完存储过程立刻CALL出来、排查ERROR 2002时不再百度前10条的实战资料包你手头可能早就有《MySQL必知必会》的PDF也收藏过B站播放量50万的“7天速成”合集——但当运维扔给你一台刚装好CentOS 7的裸机要求“把业务库搭起来主从同步要跑通明天上线”你打开文档发现全是SELECT * FROM users;这种玩具语句连mysqld.service怎么重载配置都得现搜或者在Docker里docker run -d --name mysql8 -e MYSQL_ROOT_PASSWORD123 mysql:8.0跑起来了结果Java应用死活连不上报错SSL connection error翻遍教程却没人告诉你ssl-modeDISABLED该加在JDBC URL里还是my.cnf里。这套资料不讲范式理论不画ER图玄学它拆解的是真实生产环境里最常卡住工程师的5个动作闭环安装→启动→连接→建模→排障。覆盖Linux离线安装、Docker一键部署、Workbench图形化调试、Navicat连接踩坑、以及show full processlist被kill后如何定位元凶。适合正在准备后端/DBA面试、接手遗留项目、或刚从云数据库转向自建MySQL的开发者——它不承诺“学会所有语法”但保证你下次看到ERROR 2002 (HY000)时第一反应不是重启服务而是ls -l /var/lib/mysql/mysql.sock。2. 安装与初始化从裸机到可连接服务的三步落地含离线rpm与Docker双路径MySQL安装从来不是点下一步的事。线上环境禁用root密码明文传输测试机要避开SELinux拦截socket文件Docker容器得暴露正确端口并挂载配置——这些细节直接决定你能否在5分钟内拿到一个mysql -u root -p能敲进去的终端。本节提供两套经生产验证的路径传统Linux离线rpm安装适配麒麟V10/统信UOS等国产系统和Docker标准化部署规避glibc版本冲突。所有操作均基于MySQL 8.0.33 LTS版避免新特性兼容性陷阱。2.1 离线rpm安装绕过网络依赖解决Failed to start mysqld.service的根因国产操作系统如银河麒麟V10常预装MariaDB直接yum install mysql-community-server会触发冲突。必须先卸载旧包再按依赖顺序安装rpm。资料包中rpm-packages/目录已按依赖层级排序mysql-community-common → mysql-community-libs → mysql-community-client → mysql-community-server并附带install.sh自动校验签名与依赖。# 进入rpm包目录执行安装脚本需root权限 cd /path/to/mysql-rpm-packages sudo bash install.sh # 关键检查确认socket路径与配置文件位置 sudo mysqld --verbose --help | grep Default options | head -1 # 输出应为Default options are read from the following files in the given order: # /etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf提示install.sh脚本核心逻辑是rpm -Uvh --force --nodeps逐个安装但强制跳过依赖检查前会先用rpm -qpR *.rpm预检缺失包。若提示libaio.so.1未找到需先yum install libaio——这是MySQL启动失败最常见的底层原因而非配置错误。安装完成后MySQL不会自动启动。必须手动初始化数据目录并生成临时密码# 初始化数据目录关键不执行此步service无法启动 sudo mysqld --initialize --usermysql --datadir/var/lib/mysql # 查看临时密码位于error log末尾非stdout sudo grep temporary password /var/log/mysqld.log # 输出示例A temporary password is generated for rootlocalhost: s!Kj9#pL2xQm # 启动服务并设开机自启 sudo systemctl start mysqld sudo systemctl enable mysqld # 验证socket文件是否存在ERROR 2002的根源在此 ls -l /var/lib/mysql/mysql.sock # 正确输出srwxrwxrwx. 1 mysql mysql 0 Jun 15 10:23 /var/lib/mysql/mysql.sock参数说明--datadir/var/lib/mysql指定数据目录必须与/etc/my.cnf中[mysqld] datadir值一致否则服务启动后找不到表空间--usermysql以mysql用户身份运行避免权限拒绝常见于SELinux启用环境socket路径默认为/var/lib/mysql/mysql.sock若修改需同步更新/etc/my.cnf的[client] socket和[mysqld] socket。2.2 Docker部署用docker-compose.yml固化生产级配置规避Cant connect to local MySQL server陷阱Docker方案的优势在于环境隔离但默认mysql:8.0镜像存在两个致命缺陷1未挂载自定义my.cnf导致时区、字符集无法持久化2MYSQL_ROOT_PASSWORD环境变量仅在首次初始化生效重启容器后密码失效。资料包中docker-compose.yml已修复此问题并预置SSL证书生成逻辑。# docker-compose.yml关键字段已加注释 version: 3.8 services: mysql8: image: mysql:8.0.33 container_name: mysql8-prod restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: MyPass42! # 密码必须含大小写字母数字符号 MYSQL_DATABASE: app_db # 启动时自动创建库 TZ: Asia/Shanghai # 设置时区避免NOW()返回UTC时间 volumes: - ./mysql-data:/var/lib/mysql # 数据持久化重启不丢失 - ./my.cnf:/etc/mysql/conf.d/my.cnf # 挂载自定义配置 - ./ssl:/var/lib/mysql/ssl # SSL证书目录 ports: - 3306:3306 # 映射宿主机端口 command: --default-authentication-pluginmysql_native_password --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci --max_connections500 --innodb_buffer_pool_size1G执行部署前需先生成SSL证书否则JDBC连接报SSL connection error# 在宿主机执行需openssl mkdir -p ssl cd ssl openssl genrsa -out ca-key.pem 2048 openssl req -new -x509 -nodes -sha256 -days 3650 -key ca-key.pem -out ca.pem openssl req -newkey rsa:2048 -days 3650 -nodes -keyout server-key.pem -out server-req.pem openssl rsa -in server-key.pem -out server-key.pem openssl x509 -req -in server-req.pem -days 3650 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem # 启动容器 docker-compose up -d # 验证SSL是否启用 docker exec -it mysql8-prod mysql -uroot -pMyPass42! -e SHOW VARIABLES LIKE have_ssl; # 输出have_ssl | YES参数说明--default-authentication-pluginmysql_native_password强制使用旧版认证插件兼容Navicat/旧版JDBC驱动--character-set-serverutf8mb4解决微信昵称等4字节emoji存储问题volumes挂载./my.cnf需包含[mysqld] ssl-ca/var/lib/mysql/ssl/ca.pem等SSL路径配置command中参数优先级高于my.cnf适合快速覆盖测试场景。2.3 连接验证用mysql命令行工具完成三次关键握手定位连接失败的真实位置安装成功不等于连接成功。mysql -h 127.0.0.1 -P 3306 -u root -p和mysql -S /var/lib/mysql/mysql.sock -u root -p走的是完全不同的协议栈——前者走TCP/IP后者走Unix Socket。资料包中connect-test.sh脚本会依次执行这三次验证精准定位故障环节。#!/bin/bash # connect-test.sh分层诊断脚本 echo Step 1: Socket连接验证本地文件权限 mysql -S /var/lib/mysql/mysql.sock -u root -pMyPass42! -e SELECT VERSION(); echo Step 2: TCP连接验证网络栈与bind-address mysql -h 127.0.0.1 -P 3306 -u root -pMyPass42! -e SELECT bind_address; echo Step 3: 远程TCP连接验证防火墙与user host mysql -h 192.168.1.100 -P 3306 -u root -pMyPass42! -e SELECT USER();执行后若Step 1失败说明mysqld未启动或socket路径错误Step 2失败则检查my.cnf中bind-address 127.0.0.1禁止0.0.0.0暴露公网Step 3失败需确认CREATE USER root192.168.1.% IDENTIFIED BY xxx;及firewall-cmd --permanent --add-port3306/tcp。血泪经验90%的ERROR 2002源于Step 1但工程师习惯先查防火墙——这是方向性错误。3. 建模与开发从建表语句到存储过程的生产级写法含索引设计与事务边界新手写SQL常陷入“功能实现即结束”的误区INT字段不设NOT NULL导致空值污染UPDATE不加WHERE条件全表更新存储过程用CONCAT拼接SQL引发注入。本节所有示例均来自真实电商订单系统强调可审计、可回滚、可监控三大生产属性。3.1 建表规范用CREATE TABLE语句固化5个反模式规避点资料包中schema/order.sql文件已按生产标准编写以下为关键设计逻辑CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键ID无业务含义, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务单号全局唯一用于幂等控制, user_id BIGINT UNSIGNED NOT NULL COMMENT 用户ID关联users表, status TINYINT NOT NULL DEFAULT 1 COMMENT 订单状态1待支付 2已支付 3已发货 4已完成 5已取消, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 订单金额单位分避免浮点数精度问题, created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT 创建时间精确到毫秒, updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT 更新时间, PRIMARY KEY (id), KEY idx_user_status (user_id, status) COMMENT 高频查询用户状态组合索引, KEY idx_created_at (created_at) COMMENT 按时间范围查询订单, CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE RESTRICT ON UPDATE CASCADE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT订单主表;参数与设计说明BIGINT UNSIGNED避免负数ID且BIGINT支持千亿级数据量INT上限21亿电商订单半年即破VARCHAR(32)业务单号用UUID或雪花算法生成32字符足够且比CHAR节省空间DECIMAL(10,2)金额必须用定点数FLOAT会导致0.10.2≠0.3DATETIME(3)毫秒级时间戳满足分布式系统追踪需求ON UPDATE CURRENT_TIMESTAMP(3)自动更新updated_at无需应用层维护FOREIGN KEY ... ON DELETE RESTRICT禁止级联删除防止误删用户导致订单孤儿数据。注意KEY idx_user_status (user_id, status)是复合索引顺序不可颠倒——因查询条件常为WHERE user_id ? AND status IN (?, ?)user_id必须在前才能高效使用索引。3.2 存储过程实战用proc_create_order封装订单创建全流程解决事务一致性难题电商下单需同时写订单主表、订单明细、扣减库存、生成支付单——任一环节失败必须全部回滚。资料包中procedures/create_order.sql提供完整实现重点解决三个痛点1输入参数校验2库存预占与扣减原子性3错误信息透传至调用方。DELIMITER $$ CREATE PROCEDURE proc_create_order( IN p_user_id BIGINT UNSIGNED, IN p_product_id BIGINT UNSIGNED, IN p_quantity INT UNSIGNED, OUT p_order_id BIGINT UNSIGNED, OUT p_error_msg VARCHAR(255) ) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN GET DIAGNOSTICS CONDITION 1 sqlstate RETURNED_SQLSTATE, errno MYSQL_ERRNO, text MESSAGE_TEXT; SET p_error_msg CONCAT(SQL ERROR , errno, : , text); ROLLBACK; END; START TRANSACTION; -- 1. 校验库存SELECT ... FOR UPDATE 锁定库存行 SELECT stock INTO current_stock FROM products WHERE id p_product_id FOR UPDATE; IF current_stock p_quantity THEN SET p_error_msg CONCAT(库存不足当前库存, current_stock, 需求数量, p_quantity); ROLLBACK; LEAVE proc_create_order; END IF; -- 2. 扣减库存 UPDATE products SET stock stock - p_quantity WHERE id p_product_id; -- 3. 创建订单主表 INSERT INTO orders (user_id, order_no, status, amount) VALUES (p_user_id, UUID_SHORT(), 1, p_quantity * 99.99); SET p_order_id LAST_INSERT_ID(); -- 4. 创建订单明细 INSERT INTO order_items (order_id, product_id, quantity, price) VALUES (p_order_id, p_product_id, p_quantity, 99.99); COMMIT; END$$ DELIMITER ;调用方式与参数说明CALL proc_create_order(1001, 2001, 2, order_id, error); SELECT order_id, error;OUT p_order_id返回新订单ID供后续支付接口使用OUT p_error_msg捕获所有异常包括库存不足、主键冲突等业务错误SELECT ... FOR UPDATE在库存行加行锁避免超卖高并发场景下必须UUID_SHORT()生成64位整数订单号比UUID字符串更省内存且有序。3.3 索引优化用EXPLAIN分析慢查询定位typeALL的性能黑洞资料包中queries/slow-log.sql包含典型慢查询案例。以“查询某用户最近10笔已完成订单”为例原始SQL性能极差-- ❌ 原始写法全表扫描 SELECT * FROM orders WHERE user_id 1001 AND status 4 ORDER BY created_at DESC LIMIT 10; -- ✅ 优化后命中索引 EXPLAIN SELECT id, order_no, amount, created_at FROM orders WHERE user_id 1001 AND status 4 ORDER BY created_at DESC LIMIT 10;EXPLAIN关键字段解读idselect_typetabletypepossible_keyskeyrowsExtra1SIMPLEordersrefidx_user_statusidx_user_status12Using where; Using filesorttyperef表示使用了非唯一索引查找性能良好keyidx_user_status确认命中复合索引rows12预估扫描12行远低于全表百万行ExtraUsing filesort因ORDER BY created_at不在索引中需额外排序——这是可优化点。终极优化创建覆盖索引消除filesort-- 新增索引将created_at加入索引末尾 ALTER TABLE orders ADD KEY idx_user_status_created (user_id, status, created_at);再次EXPLAINExtra变为Using index查询速度提升3倍以上。避坑提醒索引列顺序必须匹配查询条件顺序created_at必须放在最后否则WHERE user_id ? AND status ?无法利用索引。4. 排查与避坑ERROR 2002、SSL连接失败、主从延迟的5个血泪现场还原再完美的部署也会遇到突发故障。本节不讲理论只复盘5个我在生产环境凌晨三点爬起来处理的真实case每个都附带现象→原因→解决三段式诊断链。这些不是教科书答案而是你翻车时能直接抄的命令。4.1 ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock现象mysql -u root -p报错但systemctl status mysqld显示active (running)。原因MySQL配置的socket路径与客户端默认路径不一致。mysqld在/etc/my.cnf中配置socket/var/lib/mysql/mysql.sock而mysql客户端默认读取/tmp/mysql.sock。解决查看服务端socket路径sudo mysqld --verbose --help | grep socket创建软链接sudo ln -sf /var/lib/mysql/mysql.sock /tmp/mysql.sock或永久修改客户端配置在/etc/my.cnf的[client]段添加socket/var/lib/mysql/mysql.sock。4.2 JDBC连接报SSL connection error但mysql -h 127.0.0.1正常现象Spring Boot应用启动失败日志显示The server does not support SSL connections。原因MySQL 8.0默认强制SSL但JDBC URL未显式声明SSL模式。解决方案1推荐在JDBC URL中添加?useSSLfalseserverTimezoneAsia/Shanghai方案2安全在MySQL中执行ALTER USER root% REQUIRE NONE;关闭SSL强制关键验证SHOW VARIABLES LIKE require_secure_transport;返回OFF才生效。4.3show full processlist中出现大量Killed状态连接现象SHOW FULL PROCESSLIST;返回多行StateKilled但SELECT查询仍慢。原因Killed并非立即终止而是标记为“待杀死”实际清理需等待事务提交或锁释放。常见于长事务阻塞。解决定位源头SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND ! Sleep AND TIME 60;强制终止KILL 12345;12345为ID根本解决在应用层设置wait_timeout300避免连接空闲超时。4.4 主从复制延迟飙升Seconds_Behind_Master持续增长现象SHOW SLAVE STATUS\G中Seconds_Behind_Master: 3600且不下降。原因从库SQL线程被大事务阻塞如DELETE FROM logs WHERE create_time 2023-01-01。解决检查从库执行中的SQLSELECT * FROM performance_schema.events_statements_current WHERE THREAD_ID IN (SELECT THREAD_ID FROM performance_schema.threads WHERE TYPE FOREGROUND) AND SQL_TEXT IS NOT NULL;优化大事务拆分为DELETE ... LIMIT 10000循环执行启用并行复制SET GLOBAL slave_parallel_workers 4;。4.5 Navicat连接MySQL 8.0报Client does not support authentication protocol现象Navicat 12以下版本连接MySQL 8.0失败提示认证协议不支持。原因MySQL 8.0默认使用caching_sha2_password插件旧版Navicat仅支持mysql_native_password。解决临时方案ALTER USER root% IDENTIFIED WITH mysql_native_password BY MyPass42!;永久方案在my.cnf中添加default_authentication_pluginmysql_native_password重启服务。5. 进阶技巧用pt-query-digest分析慢日志构建可落地的性能基线报告性能调优不能靠猜。我曾接手一个日均10万订单的系统DBA说“数据库很稳”但业务方抱怨“查订单要5秒”。用pt-query-digest分析慢日志后发现90%的慢查询来自一个未加索引的LIKE %keyword%模糊搜索——这根本不是数据库问题而是前端搜索框没做防抖。本节教你用Percona Toolkit建立可复用的性能监控流水线输出带阈值告警的HTML报告。5.1 慢日志采集开启slow_query_log并配置合理阈值MySQL默认关闭慢日志需手动激活。资料包中my.cnf已预置生产级配置[mysqld] # 慢日志基础配置 slow_query_log ON slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1.0 # 超过1秒的查询记入慢日志 log_queries_not_using_indexes ON # 未用索引的查询也记录重要 min_examined_row_limit 1000 # 扫描行数超1000才记录减少噪音 log_output FILE # 输出到文件避免TABLE模式影响性能关键操作创建慢日志目录并授权sudo mkdir -p /var/log/mysql sudo chown mysql:mysql /var/log/mysql重启服务sudo systemctl restart mysqld验证是否生效sudo tail -f /var/log/mysql/mysql-slow.log执行SELECT SLEEP(2);应立即出现日志。提示long_query_time 1.0是黄金阈值。低于1秒的查询通常由网络或应用层引起不应归责数据库高于2秒则错过大量中间态慢查询。5.2 日志分析用pt-query-digest生成可交互的HTML报告Percona Toolkit的pt-query-digest是DBA的瑞士军刀。资料包中scripts/analyze-slow.sh封装了完整流程#!/bin/bash # analyze-slow.sh自动化分析脚本 LOG_FILE/var/log/mysql/mysql-slow.log REPORT_DIR/var/www/html/slow-report # 1. 清理旧报告 rm -rf $REPORT_DIR # 2. 生成HTML报告按响应时间TOP10排序 pt-query-digest \ --report-format html \ --output $REPORT_DIR/index.html \ --limit 10 \ --filter $event-{Bytes} 1024 \ # 过滤小查询 $LOG_FILE # 3. 生成JSON摘要供监控系统集成 pt-query-digest \ --report-format json \ --output $REPORT_DIR/summary.json \ $LOG_FILE echo Report generated at: http://$(hostname -I | awk {print $1}):8080/slow-report/执行后访问http://server-ip:8080/slow-report/报告首页即显示Top 10 Slow Queries表格每行包含RankResponse timeCallsR/CallV/MItem1123.45s (32%)1420.8697s2.33SELECT FROM orders WHERE user_id ? AND status ?关键字段解读Response time总耗时占比32%表示该SQL消耗了32%的数据库CPU时间R/Call平均每次执行耗时0.8697s即单次查询近1秒V/M变异性系数1.0说明耗时波动大可能受锁竞争影响Item参数化后的SQL模板隐藏具体值便于聚合分析。5.3 基线告警用--threshold参数触发阈值预警让DBA提前介入pt-query-digest支持阈值告警当慢查询比例超过设定值时自动发送邮件。资料包中alert-threshold.conf定义了三级告警策略# alert-threshold.conf # 当慢查询占比 5% 时触发P1告警严重 --threshold 5% # 当单次查询耗时 5s 时触发P2告警高危 --threshold Query_time 5 # 当扫描行数 10万时触发P3告警中危 --threshold Rows_examined 100000执行告警分析# 生成告警摘要不生成HTML仅输出警告 pt-query-digest \ --config /path/to/alert-threshold.conf \ --no-report \ --print-profile \ /var/log/mysql/mysql-slow.log输出示例# P1 WARNING: Slow queries account for 7.2% of total queries (threshold: 5%) # P2 WARNING: 3 queries exceed 5s (longest: 12.4s) # P3 WARNING: 12 queries examine 100000 rows落地技巧将此命令加入crontab每小时执行一次并通过mail -s MySQL Slow Alert admincompany.com发送邮件。从那以后我每次上线新功能都强制走一遍这个告警流程——不是为了证明代码没问题而是确保问题在用户投诉前就被自己发现。希望帮到你。本文还有配套的精品资源点击获取