1. SQL命令类型解析：从增删改查到数据控制
SQL作为关系型数据库的标准查询语言，其命令类型构成了数据库操作的基础骨架。根据功能差异，SQL命令主要分为以下五类：
1.1 数据查询语言（DQL）
SELECT语句是DQL的核心，其基础语法结构为：
SELECT [DISTINCT] 列名 FROM 表名 [WHERE 条件] [GROUP BY 分组列] [HAVING 分组条件] [ORDER BY 排序列] [LIMIT 行数]实际开发中容易忽略的是SELECT执行顺序：
- FROM子句确定数据源
- WHERE条件过滤行数据
- GROUP BY执行分组
- HAVING过滤分组结果
- SELECT选择输出列
- ORDER BY排序结果
- LIMIT限制返回行数
注意：在包含JOIN的复杂查询中，执行顺序会发生变化，WHERE条件可能在不同阶段被应用
1.2 数据操作语言（DML）
DML包含三类核心操作：
- INSERT：单行插入与批量插入语法差异
-- 单行插入 INSERT INTO 表名(列1,列2) VALUES(值1,值2); -- 多行插入（MySQL特有） INSERT INTO 表名(列1,列2) VALUES(值1,值2),(值3,值4);- UPDATE：务必包含WHERE条件避免全表更新
UPDATE 表名 SET 列1=值1 WHERE 条件;- DELETE：与TRUNCATE的本质区别（可回滚vs不可回滚）
1.3 数据定义语言（DDL）
DDL操作会隐式提交事务，主要包含：
- CREATE：建表时的引擎选择（InnoDB vs MyISAM）
- ALTER：在线DDL操作的风险控制
- DROP：级联删除的潜在危险
- TRUNCATE：比DELETE更快的清表方式
1.4 数据控制语言（DCL）
权限管理的两个核心命令：
GRANT 权限 ON 数据库.表 TO '用户'@'主机'; REVOKE 权限 ON 数据库.表 FROM '用户'@'主机';1.5 事务控制语言（TCL）
事务处理的四大特性（ACID）通过以下命令实现：
- BEGIN/START TRANSACTION：显式开启事务
- COMMIT：提交时的两阶段提交过程
- ROLLBACK：回滚到保存点的语法
- SAVEPOINT：创建事务中的还原点
2. 数据库会话管理深度剖析
2.1 会话生命周期管理
典型数据库会话流程：
- 建立连接（三次握手）
- 身份认证（密码验证或SSL证书）
- 分配会话ID和内存区域
- 执行SQL语句
- 事务处理
- 连接关闭（正常断开或超时终止）
连接池配置关键参数：
max_connections = 200 # 最大连接数 wait_timeout = 28800 # 非活动超时(秒) interactive_timeout = 28800 # 交互式会话超时2.2 连接池技术实现
主流连接池对比：
| 特性 | HikariCP | Druid | Tomcat JDBC |
|---|---|---|---|
| 获取连接速度 | 最快 | 中等 | 较慢 |
| 监控功能 | 基础 | 完善 | 有限 |
| 泄漏检测 | 支持 | 支持 | 部分支持 |
| 适合场景 | 高性能需求 | 企业级监控需求 | 嵌入式应用 |
Spring Boot配置示例：
spring.datasource.hikari.connection-timeout=30000 spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.idle-timeout=6000002.3 会话状态监控
MySQL查看活动会话：
SHOW PROCESSLIST;关键状态列解析：
- Sleep：空闲连接
- Query：正在执行查询
- Locked：等待锁释放
- Copying to tmp table：使用临时表
2.4 长事务与会话锁定
识别危险会话的特征：
- 执行时间超过30秒的UPDATE/DELETE
- 持有锁但长时间不提交的事务
- 产生大量undo日志的操作
应急处理方案：
-- 查询阻塞会话 SELECT * FROM information_schema.innodb_trx WHERE trx_state = 'LOCK WAIT'; -- 终止会话 KILL [CONNECTION|QUERY] process_id;3. 高级会话控制技巧
3.1 会话变量设置
常用会话级配置：
SET SESSION sql_mode = 'STRICT_TRANS_TABLES'; -- 严格模式 SET SESSION wait_timeout = 3600; -- 自定义超时 SET SESSION max_execution_time = 10000; -- 查询超时(ms)3.2 连接路由策略
读写分离场景下的路由规则：
- 自动识别SELECT路由到从库
- 事务内的所有操作强制走主库
- 存储过程默认路由到主库
- 包含@@session变量的查询走主库
3.3 安全会话实践
防注入措施：
- 始终使用预编译语句
- 最小权限原则分配账号
- 敏感操作审计日志记录
SSL连接配置示例：
spring.datasource.url=jdbc:mysql://localhost:3306/db?useSSL=true&requireSSL=true spring.datasource.properties.serverSslCert=/path/to/server-cert.pem4. 性能优化实战案例
4.1 连接风暴应对
现象：应用重启后连接数激增 解决方案：
- 实现连接延迟建立
- 采用指数退避重试策略
- 增加连接获取超时时间
4.2 查询超时控制
MySQL 8.0+的优化：
-- 设置会话级超时 SET SESSION max_execution_time = 2000; -- 单个查询超时（MySQL 8.0+） SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM large_table;4.3 批量操作优化
JDBC批量插入最佳实践：
// 关键参数设置 connection.setAutoCommit(false); statement.setFetchSize(1000); // 使用addBatch() for(int i=0; i<10000; i++){ preparedStatement.setInt(1, i); preparedStatement.addBatch(); if(i % 1000 == 0){ preparedStatement.executeBatch(); } } preparedStatement.executeBatch(); connection.commit();5. 异常处理与问题排查
5.1 常见连接错误
错误代码对照表：
| 错误码 | 原因 | 解决方案 |
|---|---|---|
| 1040 | 连接数超过最大值 | 增加max_connections参数 |
| 1205 | 锁等待超时 | 优化事务或kill阻塞会话 |
| 2003 | 无法连接到数据库 | 检查网络和防火墙设置 |
| 2013 | 查询过程中连接丢失 | 增加wait_timeout或检查网络 |
5.2 连接泄漏检测
诊断步骤：
- 监控连接增长趋势
- 对比应用连接池与数据库实际连接数
- 检查未关闭的ResultSet/Statement
- 使用连接池的泄漏检测功能
5.3 慢查询分析
定位方法：
-- 开启慢查询日志 SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2; -- 分析执行计划 EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE user_id=1000;典型性能问题模式：
- 全表扫描（type=ALL）
- 临时表使用（Using temporary）
- 文件排序（Using filesort）
- 索引合并（index_merge）
6. 分布式会话管理
6.1 读写分离架构
代理层配置要点：
# ProxySQL配置示例 INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'master1',3306), (20,'slave1',3306), (20,'slave2',3306); INSERT INTO mysql_query_rules (rule_id,active,match_pattern,destination_hostgroup,apply) VALUES (1,1,'^SELECT.*FOR UPDATE',10,1), (2,1,'^SELECT',20,1);6.2 分库分表场景
ShardingSphere配置示例：
spring.shardingsphere.datasource.names=ds0,ds1 spring.shardingsphere.sharding.tables.order.actual-data-nodes=ds$->{0..1}.order_$->{0..15} spring.shardingsphere.sharding.tables.order.table-strategy.inline.sharding-column=order_id spring.shardingsphere.sharding.tables.order.table-strategy.inline.algorithm-expression=order_$->{order_id % 16}6.3 多租户隔离方案
三种实现模式对比：
| 方案类型 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| 独立数据库 | 每个租户单独数据库实例 | 完全隔离，安全性最高 | 资源消耗大，成本高 |
| 共享数据库 | 通过schema隔离租户数据 | 资源利用率高 | 开发复杂度增加 |
| 共享数据表 | 通过tenant_id列区分 | 维护最简单 | 数据安全风险较高 |
在MySQL中创建租户专属会话：
-- 为特定租户设置会话变量 SET @tenant_id = 123; CREATE VIEW tenant_data AS SELECT * FROM all_data WHERE tenant_id = @tenant_id;
