在高并发场景下，如何优化MySQL（或分布式数据库）以支撑360安全产品的数据存储（如用户行为日志、病毒特征库）？请举例说明索引设计、读写分离、分库分表策略，以及如何处理事务和锁问题。

360服务端开发工程师-Golang难度：困难

答案

1) 【一句话结论】：在高并发场景下优化MySQL，需通过索引优化（考虑维护成本与查询效率）、读写分离（主从复制分担读压力）、分库分表（水平/垂直分库分表解决数据量），结合事务隔离级别（如读已提交）与锁机制（行锁代替表锁），平衡性能与一致性，支撑360用户行为日志、病毒特征库等高并发存储需求。

2) 【原理/概念讲解】：

索引设计：索引是数据库的“目录”，加速数据检索。复合索引是多个列的组合索引，遵循“最左前缀”原则（如user_id+log_time），覆盖索引是索引包含查询所需所有字段（减少回表）。更新操作时，复合索引需更新多个索引项，增加I/O开销；覆盖索引减少回表但需确保索引列顺序匹配查询条件。
读写分离：主从复制架构，主库（Master）处理写操作（如写入日志），从库（Slave）异步复制数据，处理读请求。从库可配置多个副本，分担读压力。适用于读多写少场景（如360日志查询）。
分库分表：水平分库（按业务或数据范围分库，如病毒特征库按特征类型分库），水平分表（按时间或ID分表，如日志按月分表），垂直分库（按表分库，如用户表、行为表分库）。水平分库解决单库数据量过大，水平分表解决单表数据量过大。
事务与锁：事务保证数据一致性，锁（行锁、表锁）控制并发。隔离级别（如读已提交）决定并发控制粒度，读已提交可减少锁等待，但可能存在不可重复读；行锁比表锁粒度细，减少并发阻塞。

3) 【对比与适用场景】：

索引类型对比：
| 索引类型 | 定义 | 特性 | 使用场景 | 注意点 |
|----------|------|------|----------|--------|
| B树索引 | 树形结构，支持范围查询 | 顺序访问，查询效率高 | 主键、外键、常用查询字段 | 占用空间大，更新慢 |
| 哈希索引 | 哈希表结构，支持等值查询 | 查询速度快，不支持范围 | 主键、唯一键（等值查询） | 不支持范围查询 |
| 覆盖索引 | 索引包含查询所需所有字段 | 减少回表，提升性能 | 查询字段在索引中 | 需确保索引列顺序正确 |
读写分离对比：
| 方式 | 定义 | 优点 | 缺点 | 适用场景 |
|------|------|------|------|--------|
| 主从复制 | 主写从读，从库异步复制 | 分担读压力，提升读性能 | 从库数据延迟，主库故障时从库不可用 | 读多写少场景（如日志、缓存） |
| 主主复制 | 多主库，互为从库 | 提升写性能，高可用 | 需解决写冲突（如事务提交顺序） | 写多读少，需事务一致性 |
分库分表策略对比：
| 策略 | 定义 | 优点 | 缺点 | 适用场景 |
|------|------|------|------|--------|
| 水平分库 | 按业务或数据范围分库（如用户表按ID哈希分库） | 单库数据量小，查询快 | 跨库关联查询复杂 | 大数据量，业务拆分 |
| 水平分表 | 按时间或ID分表（如日志按月分表） | 单表数据量小，查询快 | 需要分表键，关联查询复杂 | 时间序列数据（如日志、监控） |
| 垂直分库 | 按表分库（如用户表、行为表分库） | 减少单库表数，提升性能 | 跨库事务复杂 | 表结构复杂，表数多 |

结论总结：360场景下，用户行为日志读多写少，用主从复制+复合索引+覆盖索引；病毒特征库大数据量，用水平分库（按特征类型），水平分表（按时间）结合，事务用读已提交，行锁减少锁冲突。

4) 【示例】：

复合索引与覆盖索引示例：
用户行为日志表（user_action_log）：

CREATE TABLE user_action_log (
    log_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    action_type VARCHAR(20) NOT NULL,
    log_time TIMESTAMP NOT NULL,
    log_data JSON,
    INDEX idx_user_id_log_time (user_id, log_time),  -- 复合索引，最左前缀
    INDEX idx_log_time_user_id (log_time, user_id)  -- 另一种顺序，查询时需注意
);
-- 覆盖索引示例：查询某用户某时间段行为，索引包含user_id, log_time, action_type
SELECT user_id, action_type, log_time FROM user_action_log WHERE user_id = 1 AND log_time BETWEEN '2024-01-01' AND '2024-01-31';
-- 索引包含所有查询字段，无需回表，提升性能

分库分表示例（水平分库哈希分库导致热点）：
病毒特征库表（virus_feature）：

-- 假设按特征类型哈希分库，类型1-3的库为库1，4-6的库为库2
CREATE TABLE virus_feature_1 (
    feature_id BIGINT PRIMARY KEY,
    feature_type INT NOT NULL,
    feature_data BLOB,
    INDEX idx_feature_type (feature_type)
);
CREATE TABLE virus_feature_2 (
    feature_id BIGINT PRIMARY KEY,
    feature_type INT NOT NULL,
    feature_data BLOB,
    INDEX idx_feature_type (feature_type)
);
-- 热点问题：若特征类型1（如常见病毒）数据量极大，所有请求都打到库1，导致热点。解决：一致性哈希或轮询，或按特征ID分片（如特征ID哈希到多个库）

分库分表后跨库关联查询优化（预聚合）：
假设用户行为日志按月分表（user_action_log_202401, user_action_log_202402），病毒特征库按类型分库（virus_feature_type1, virus_feature_type2）。查询某用户某月行为与特征匹配：

-- 预聚合表：按月聚合日志，存储月内行为统计
CREATE TABLE user_action_month_agg (
    user_id BIGINT,
    month DATE,
    action_count INT,
    feature_match_count INT,
    INDEX idx_user_month (user_id, month)
);
-- 预聚合后查询：减少实时JOIN压力
SELECT u.user_id, u.action_count, f.feature_match_count
FROM user_action_month_agg u
JOIN virus_feature_type1 f ON u.user_id = f.user_id AND u.month = f.month;

5) 【面试口播版答案】：
“在高并发场景下优化MySQL，核心是通过索引优化、读写分离、分库分表提升性能，同时处理事务与锁。比如360的用户行为日志，读多写少，我们建了user_id和log_time的复合索引，还用了覆盖索引，减少回表。读写分离用主从复制，主库写日志，从库处理查询，分担读压力。分库方面，病毒特征库按特征类型分库，避免单库数据量过大。事务方面，选择读已提交隔离级别，减少锁等待，用行锁代替表锁。分库分表后，跨库关联查询用预聚合表，减少实时JOIN压力。这样能平衡性能与一致性，支撑高并发需求。”（约100秒）

6) 【追问清单】：

问题1：如何选择分库分表策略？
回答要点：根据数据量、查询模式，水平分库分表适合大数据量，垂直分库适合表结构复杂。比如用户行为日志按时间分表，病毒特征库按类型分库。
问题2：读写分离的延迟如何处理？
回答要点：通过多个从库、延迟监控（如binlog延迟），或结合缓存（如Redis缓存热点数据），减少延迟影响。
问题3：分表后关联查询如何优化？
回答要点：用分表键（如时间）或预聚合（如按月聚合日志），或分库后跨库查询（如JOIN时合并数据）。
问题4：事务隔离级别选择依据？
回答要点：读多写少场景用读已提交，减少锁等待；强一致性需求用可重复读，但需考虑锁等待。360日志业务对一致性要求较高，读已提交足够。
问题5：高并发下锁升级问题？
回答要点：优化锁粒度，用行锁代替表锁，加锁时缩小范围（如按user_id+时间范围加锁），减少并发阻塞。

7) 【常见坑/雷区】：

复合索引顺序错误：如按log_time+user_id建索引，但查询时按user_id+log_time，导致索引失效。
覆盖索引设计不当：索引未包含所有查询字段，仍需回表。
分库分表热点问题：哈希分库导致热点，未解决导致单库压力过大。
事务隔离级别选择不当：读未提交可能导致脏读，读已提交可能锁等待。
读写分离延迟未监控：导致数据不一致或查询延迟。