生产常见问题
1. 事务问题
是否需要事务取决于具体场景：
基础操作无需事务
若仅执行单条插入或更新语句（如
INSERT或UPDATE），通常无需显式开启事务。数据库本身会通过ACID特性保障操作的完整性，即使出现异常也会自动回滚。 12复杂操作需显式管理
当涉及多步骤操作（如插入后更新、多表联动更新等），建议使用事务以确保整体一致性。例如，用户注册流程可能涉及用户信息插入和积分更新，此时需显式开启事务并提交或回滚整个操作。 3
业务异常处理场景
若业务逻辑需要判断操作结果（如更新条数不匹配时抛异常），即使单条语句也可能需要事务管理。这是为了确保异常抛出后，数据库状态能回滚到操作前状态，避免数据不一致
2. distinct性能问题
DISTINCT操作对MySQL性能的影响并非绝对，其表现取决于具体使用场景和优化措施：
性能影响的关键因素
- 数据量：处理大量数据时，DISTINCT需对结果进行排序和去重，可能导致CPU和内存消耗增加。 12
- 索引优化：若查询字段有索引，DISTINCT可显著提升效率；若无索引，可能引发全表扫描，大幅降低性能。 12
- 查询设计：
- 减少查询列数和行数，仅对必要列进行去重。 4
- 使用分页查询或临时表处理大数据量。 14
优化建议
- 建立索引：确保查询列有索引，避免全表扫描。 12
- 分页查询：对大表采用分页方式，减少单次查询数据量。 14
- 减少数据类型负担：将可变长度字段（如VARCHAR）转换为固定长度类型（如CHAR），降低处理复杂度。 1
适用场景
DISTINCT适用于需要确保数据唯一性的场景（如统计不同城市、邮箱等），但需根据数据规模提前评估性能风险
3. redis问题
这篇文章介绍了大key优化：https://blog.csdn.net/code_fly_/article/details/151629586?spm=1001.2014.3001.5501