先看执行计划使用 EXPLAIN / EXPLAIN ANALYZE，重点关注是否出现全表扫描、错误的索引选择、扫描行数过多等问题。检查索引给 WHERE、JOIN、ORDER BY、GROUP BY 中高频使用的字段建立合适索引。注意联合索引的字段顺序和最左匹配原则。减少扫描数据量避免 SELECT *，尽量缩小查询范围，减少不必要的数据排序、分组和临时表操作。

数据库范式是规范数据库表结构、减少数据冗余和异常的一套规则。1NF：字段不可再分，每个字段只能存一个值。2NF：满足1NF，非主属性必须完全依赖整个主键。3NF：满足2NF，非主属性不能依赖其他非主属性。简单说：1NF管原子性，2NF管部分依赖，3NF管传递依赖。

索引类型核心特点适用场景B+Tree 索引有序、支持范围查询最常用，=、>、、BETWEEN、ORDER BY、LIKE 'xxx%'Hash 索引哈希定位，等值查询快= 精确匹配，不适合范围查询全文索引针对文本内容建立倒排结构文章、评论、文档等关键词搜索空间索引针对空间/地理数据经纬度、GIS、附近地点查询唯一索引限制索引列不能重复用户名、手机号、身份证号等唯一字段联合索引多个字段组合建立索引多条件查询，例如 WHERE a=? AND b=?聚簇索引数据行本身按照索引组织InnoDB 主键索引，适合主键查询和范围查询非聚簇索引索引和数据记录分开存储辅助索引，减少全表扫描

我觉得核心还是定位不一样。MySQL 更偏传统关系型数据库，而 GaussDB 更强调企业级场景下的高可用、分布式能力和数据安全。尤其是面对大规模数据和高并发场景时，GaussDB 在架构上会更有优势。  

主要是为了让网络具备学习非线性关系的能力。如果每一层都只是线性计算，就算堆很多层，本质上还是一个线性模型，解决不了复杂的问题。加上 ReLU、Sigmoid 这类激活函数之后，网络才能拟合更复杂的关系。简单来说，没有激活函数，神经网络堆再深也没什么意义。  

数据库日志的归档策略：binlog（二进制日志）用于主从复制和数据恢复，但很多开发者忽略 binlog 的过期时间和归档策略。binlog 文件过大会导致恢复时间过长，未归档则会占用大量磁盘空间。尤其在主从复制场景下，binlog 不一致会导致从库同步失败，这是数据丢失的重要原因。

查询执行计划的 “.rows” 与 “filtered” 字段：多数开发者会看执行计划的 “type”（访问类型）和 “key”（使用的索引），但忽略 “rows”（预估扫描行数）和 “filtered”（过滤后行比例）。这两个字段的乘积才是实际需要处理的行数，若 rows * filtered 过大，即使使用了索引，性能仍会很差。 

外键的运维成本：外键虽能保证数据一致性，但会导致关联表的插入、更新、删除操作性能下降，尤其在高并发场景下，外键约束的检查会成为瓶颈。很多开发者在设计阶段过度依赖外键，忽略分库分表后外键无法跨库生效的问题，导致后期架构重构困难。 

临时表与内存表的区别：临时表（CREATE TEMPORARY TABLE）仅对当前会话可见，会话结束后自动删除；内存表（CREATE TABLE ... ENGINE=MEMORY）存储在内存中，服务器重启后数据丢失。很多开发者混淆两者，用内存表存储临时数据，导致重启后数据丢失，或用临时表存储大量数据，导致磁盘 IO 飙升。 

连接池的配置误区：连接池大小并非越大越好，过大的连接数会导致数据库上下文切换频繁，反而降低性能；过小则会出现连接等待。很多开发者仅关注最大连接数，忽略最小空闲连接数和连接超时时间的配置，导致高并发下出现 “连接泄露” 或 “连接池耗尽” 问题。