MySQL面试题2025 逐日20道【其四】

1、你们生产情况的 MySQL 中使用了什么事务隔离级别？为什么？ 中等

在生产情况中，MySQL数据库的事务隔离级别通常由开发团队或数据库管理员根据应用的需求来设定。MySQL支持四种标准的事务隔离级别：

• 读未提交（Read Uncommitted）：事务中的修改，纵然未提交，对其他事务也都是可见的。这个级别会导致许多并发问题，如脏读、不可重复读和幻读。
  
• 读已提交（Read Committed）：一个事务开始时，只能瞥见已经提交的事务所做的修改。这可以防止脏读，但不可重复读和幻读仍然可能发生。
  
• 可重复读（Repeatable Read）：在整个事务期间，任何外部提交的更改都不会影响该事务的查询结果。这是MySQL默认的隔离级别，它解决了不可重复读的问题，但在某些情况下仍可能出现幻读。
  
• 序列化（Serializable）：提供最严格的隔离级别，全部事务依次逐个实验，这样事务的并发度会很低，但完全制止了脏读、不可重复读以及幻读。
  

对于为什么选择某一种隔离级别，这取决于应用步调的具体需求。例如，在金融体系中，数据的同等性和准确性是最重要的，因此可能会选择较高的隔离级别如“可重复读”或“序列化”。而在一些对性能要求较高且能容忍一定并发问题的场景下，则可能会选择较低的隔离级别以提高并发性能。
在MySQL的InnoDB存储引擎中，默认使用的是“可重复读（Repeatable Read）”隔离级别。这是由于在这个级别上，InnoDB可以通过多版本并发控制（MVCC）机制很好地平衡并发性能和数据同等性。
假如你需要确切了解某个特定生产情况下的MySQL配置，你应该直接查看谁人情况中的配置设置或者咨询负责维护该数据库的管理员。
2、为什么阿里巴巴的 Java 手册不保举使用存储过程？ 中等

阿里巴巴的Java开发手册不保举使用存储过程，主要是基于以下几个考虑：

• 维护本钱：存储过程将业务逻辑部分或全部嵌入到数据库中，这可能会增加维护本钱。由于它们通常不是由应用步调的同一团队管理，而是由数据库管理员（DBA）负责。这意味着对于应用开发者来说，明白和修改这些存储过程可能需要额外的学习和沟通本钱。
  
• 移植性问题：不同的数据库体系有不同的存储过程语法和特性。假如你的应用步调将来需要迁移到另一个数据库平台，那么你可能不得不重新编写全部的存储过程。相比之下，假如业务逻辑在应用步调代码中实现，则更轻易举行跨数据库移植。
  
• 调试困难：存储过程的调试往往比普通应用步调代码更复杂。许多当代IDE提供了强大的工具来帮助开发者调试应用步调代码，但对于存储过程的支持则相对较弱。别的，在分布式情况中跟踪事务边界和错误也会变得更加棘手。
  
• 版本控制挑战：当业务逻辑被编码进存储过程中时，对其举行版本控制就变得复杂了。通常情况下，应用步调代码可以很好地与版本控制体系集成，但存储过程的变更管理则不轻易做到这一点。
  
• 测试未便：单元测试和集成测试存储过程要比测试普通的应用步调代码更加困难。由于存储过程精密耦合于数据库，所以为了有效地测试它们，通常需要模仿整个数据库情况，这增加了测试的复杂度。
  
• 性能优化限制：固然某些操纵通过存储过程可以在数据库层面得到性能提升，但这也可能导致对数据库内部机制过分依赖，使得优化选择受到局限。而且，随着数据库技术的发展，许多原本需要通过存储过程实现的性能优化现在可以通过查询优化器主动完成。
  
• 安全性考量：存储过程的实验权限通常赋予给特定用户，这可能引发安全风险，尤其是在处理敏感数据时。同时，存储过程中的SQL注入毛病也有可能被使用，尽管这种风险同样存在于直接编写的SQL语句中。
  

综上所述，阿里巴巴的Java开发手册倾向于鼓励将业务逻辑保持在应用步调层面上，以确保更好的可维护性、移植性和安全性，同时也简化了开发流程。然而，这并不意味着存储过程没有其应用场景；在一些特定的情况下，比如大批量数据处理或者复杂的数据库级逻辑，存储过程仍然是一个有效的工具。每个项目都应该根据自身的需求和技术栈做出最得当的选择。
3、如何实现数据库的不停服迁移？ 中等

实现数据库的不停服迁移（即在线迁移）是一个复杂的过程，它要求在不影响现有体系服务的前提下，将数据从一个数据库情况迁移到另一个。以下是实现不停服数据库迁移的一样平常步调和策略：
1. 评估与规划

• 需求分析：明白迁移的目的、目的数据库的选择以及业务影响。
  
• 风险评估：辨认潜在的风险，并制定应对步调。
  
• 资源准备：确保有足够的硬件资源来支持新旧体系的并行运行。
  

2. 选择适当的迁移工具和技术

• 根据源数据库和目的数据库的类型选择合适的迁移工具，如AWS Database Migration Service, GoldenGate等。
  
• 假如是同构数据库间的迁移，可以考虑使用备份恢复或复制技术。
  

3. 架构设计

• 双写机制：在某些情况下，可以在一段时间内同时向旧数据库和新数据库写入数据，确保两个数据库的数据同等性。
  
• 读写分离：通过署理或中央件实现读写分离，减轻源数据库压力，并为渐渐切换到新的数据库做好准备。
  

4. 数据同步

• 全量迁移：首先举行一次完备的数据迁移，把全部历史数据从源库迁移到目的库。
  
• 增量同步：使用日志剖析或者变更数据捕获（CDC）技术，持续地将新增或修改的数据从源库同步到目的库，保持两者的数据同等。
  

5. 验证

• 在迁移过程中定期检查数据的同等性和完备性，确保没有遗漏或错误。
  
• 举行充实的功能测试，以保证应用步调在新情况中可以或许正常工作。
  

6. 切换

• 流量切分：逐渐将一部分流量导向新的数据库，观察性能和稳定性。
  
• 最终切换：当确认齐备正常后，可以选择一个合适的时间点完成全部流量的切换，通常会选择业务低峰期。
  

7. 监控与优化

• 在切换完成后，密切监控新数据库的表现，包罗性能指标、错误率等。
  
• 对应用层代码及数据库配置举行必要的调整，以达到最佳性能。
  

8. 回滚筹划

• 制定具体的回滚方案，以防万一出现问题可以迅速回到原来的情况。
  

注意事项：

• 沟通协调：在整个迁移过程中，与全部相关方保持精良的沟通非常重要，确保他们了解进度和可能的影响。
  
• 用户通知：假如有可能的话，提前告知用户可能会出现短暂的服务停止（纵然是非常短的时间），以便他们有所准备。
  

不同的项目和情况可能需要定制化的解决方案，因此上述建议应根据具体情况举行适当调整。
4、MySQL 数据库的性能优化方法有哪些？ 中等

MySQL数据库的性能优化可以从多个方面举行，包罗但不限于查询优化、索引优化、配置调整、硬件升级等。下面是一些常见的MySQL性能优化方法：
查询优化

• 分析慢查询：使用slow query log来辨认实验时间过长的SQL语句，并对其举行优化。
  
• 制止全表扫描：尽量减少或消除不必要的全表扫描操纵，确保查询可以或许使用到索引。
  
• 优化JOIN操纵：尽量减少复杂的多表连接，或者通过适当的索引来加速JOIN。
  
• 限制返回结果集巨细：对于不需要全部数据的情况，使用LIMIT来限制返回的结果数目。
  
• 使用合适的函数和表达式：某些内置函数和表达式的服从较低，可以考虑用更高效的替代方案。
  

索引优化

• 创建有效的索引：为经常出现在WHERE子句中的列创建索引，特别是那些用于过滤、排序或分组的字段。
  
• 选择合适的索引类型：根据查询的特点选择B树、哈希或其他类型的索引。
  
• 定期重建索引：随着数据的变革，索引可能会变得不再高效，定期重建可以帮助保持最佳性能。
  
• 制止过分索引：过多的索引会增加写入本钱，并占用额外的存储空间。
  

配置调整

• 调整缓冲区巨细：适当增大InnoDB Buffer Pool Size、Key Buffer Size等内存参数，以提高缓存掷中率。
  
• 优化并发设置：如调整innodb_thread_concurrency、max_connections等参数，以顺应应用步调的需求。
  
• 启用查询缓存（已废弃）：尽管MySQL 8.0已经移除了查询缓存功能，但在之前的版本中，它可以在一定程度上提升读麋集型应用的性能。
  

数据库结构优化

• 归档旧数据：将不常访问的历史数据移动到单独的归档表中，减少主表的数据量。
  
• 分区表：对大型表实施水平或垂直分区，以便更好地管理和访问数据。
  
• 选择合适的数据类型：尽可能使用较小的数据类型，例如INT取代BIGINT，以节省存储空间并加速处理速度。
  

硬件与网络优化

• 升级硬件资源：增加CPU核心数、扩展RAM容量、采取SSD硬盘等方式来增强服务器性能。
  
• 优化网络带宽：确保数据库服务器和客户端之间的网络连接稳定且具有足够的带宽。
  

应用层优化

• 批量处理：当需要插入大量数据时，尽量采取批量插入而不是逐行插入。
  
• 异步处理：对于非实时要求的任务，可以考虑使用消息队列等机制来举行异步处理。
  

日志与监控

• 启用慢查询日志和错误日志：帮助诊断问题。
  
• 使用监控工具：如Percona Monitoring and Management (PMM)、Prometheus + Grafana等，持续跟踪数据库的运行状态。
  

以上只是一些基本的优化策略，具体的优化步调应该基于实际的工作负载和业务需求。在举行任何重大变更之前，建议先在一个测试情况中充实验证其效果。
5、MySQL 中 InnoDB 存储引擎与 MyISAM 存储引擎的区别是什么？ 中等

MySQL的InnoDB和MyISAM是两种不同的存储引擎，它们在特性、性能、功能等方面存在显著差别。以下是两者的主要区别：
事务支持

• InnoDB：支持ACID兼容的事务处理，提供提交、回滚和崩溃恢复本事，确保数据的同等性和持久性。
  
• MyISAM：不支持事务，这意味着一旦写入操纵开始，纵然遇到问题也不能回滚。
  

锁机制

• InnoDB：使用行级锁（Row-level Locking），答应并发控制更细粒度，在高并发场景下表现精彩。
  
• MyISAM：采取表级锁（Table-level Locking），当一个线程正在写入时，整个表都会被锁定，其他读写请求必须等候，这在高并发情况下可能会导致性能瓶颈。
  

外键束缚

• InnoDB：支持外键束缚，可以用来维护不同表之间的参照完备性。
  
• MyISAM：不支持外键束缚，因此不具备这一级别的数据完备性保障。
  

索引结构

• InnoDB：使用聚集索引（Clustered Index），将主键与数据行一起存储，非主键索引则是指向主键的指针。这种设计有助于加速基于主键的查询。
  
• MyISAM：使用的是非聚集索引（Non-clustered Index），即索引和数据是分开存储的。
  

缓存策略

• InnoDB：有专门的缓冲池（Buffer Pool）来缓存数据和索引页，提高了I/O服从。
  
• MyISAM：只缓存索引，数据文件由操纵体系负责缓存。
  

破坏恢复

• InnoDB：具有主动恢复功能，可以通过重做日志（Redo Log）和撤销日志（Undo Log）举行崩溃恢复。
  
• MyISAM：缺乏内置的恢复机制，假如发生崩溃，可能需要手动修复破坏的表。
  

存储限制

• InnoDB：单个表的数据巨细理论上没有限制，受限于磁盘空间和操纵体系对文件巨细的支持。
  
• MyISAM：单个表的最大容量为256TB（取决于体系参数设置）。
  

内存使用

• InnoDB：内存消耗通常比MyISAM要大，由于它需要额外的空间来管理事务、锁定和其他内部操纵。
  
• MyISAM：相对较低的内存占用。
  

全文搜刮

• InnoDB：从MySQL 5.6版本开始也支持全文索引，但在此之前只有MyISAM支持。
  
• MyISAM：早期版本中提供了全文索引的支持。
  

综上所述，InnoDB更得当那些需要高并发写入、事务支持以及数据完备性的应用；而MyISAM则适用于以读取为主的应用，并且在某些特定情况下（如全文索引需求）可能是一个更好的选择。不过，随着MySQL的发展，许多以前仅限于MyISAM的功能已经被添加到了InnoDB中，使得InnoDB成为了大多数应用场景下的首选。
MySQL 的查询优化器如何选择实验筹划？ 中等
数据库
MySQL
数据库体系结构
7、什么是数据库的逻辑删除？数据库的物理删除和逻辑删除有什么区别？ 简朴

数据库中的逻辑删除和物理删除是两种不同的数据删除方式，它们在实现机制、应用场景以及对体系的影响方面都有显著的区别。
逻辑删除（Logical Deletion）

• 定义：逻辑删除并不是真正地从数据库中移除记录，而是通过设置一个或多个字段（如is_deleted标志位）来标记这条记录为已删除状态。
  
• 长处：
  
  
  
  • 可以保持数据的完备性，答应恢复误删的数据。
    
  • 减少对外部体系的打击，由于关联的数据不会立即丢失。
    
  • 对于审计追踪非常有用，可以记录哪些记录被删除了及其删除时间等信息。
    
  
  
• 缺点：
  
  
  
  • 需要在查询时额外考虑这些“已删除”但仍然存在于表中的记录，可能会导致性能下降。
    
  • 数据库占用的空间不会由于逻辑删除而减少，长期积累可能导致存储问题。
    
  
  

物理删除（Physical Deletion）

• 定义：物理删除是指直接从数据库中永久移除记录。这通常意味着该记录将不再出现在任何查询结果中，并且无法轻易恢复。
  
• 长处：
  
  
  
  • 简化了数据库结构，减少了存储空间。
    
  • 提升查询性能，由于不需要处理那些被标记为已删除但实际上还存在的记录。
    
  
  
• 缺点：
  
  
  
  • 一旦实验，很难恢复数据，除非有定期备份。
    
  • 假如存在外键束缚或其他依赖关系，物理删除可能会影响到其他相关表的数据同等性。
    
  
  

区别

• 数据保存与否：逻辑删除保存了原始数据，只是改变了其可见性；物理删除则是彻底扫除了数据。
  
• 性能影响：随着逻辑删除记录数目的增长，查询性能可能会受到影响，而物理删除则有助于提高性能。
  
• 恢复可能性：逻辑删除后可以较轻易地恢复数据，而物理删除后的恢复难度较大，依赖于是否有有效的备份策略。
  
• 存储需求：逻辑删除会持续占用存储空间，而物理删除可以开释这部分空间。
  
• 应用适用性：对于需要维护历史记录或支持数据恢复的应用场景，逻辑删除更为合适；而对于确保数据安全性和隐私保护的应用，则更倾向于使用物理删除。
  

选择哪种删除方式取决于具体的应用需求、业务规则以及对数据完备性和性能的要求。在某些情况下，也可以联合两者的上风，例如先举行逻辑删除，在一定周期后再举行物理删除。
8、什么是数据库的逻辑外键？数据库的物理外键和逻辑外键各有什么优缺点？ 中等

在数据库设计中，逻辑外键和物理外键是两种不同的实现方式来维护表间的关系。它们各自有特定的应用场景、长处和缺点。
物理外键（Physical Foreign Key）

• 定义：物理外键是指在数据库模式中正式定义的外键束缚。它通过数据库管理体系（DBMS）逼迫实施参照完备性规则。
  
• 长处：
  
  
  
  • 数据同等性：确保了子表中的记录总是引用父表中存在的有效记录，防止孤立记录的存在。
    
  • 主动维护：当父表的数据发生变革时（如更新或删除），DBMS可以根据设定的举动（如级联更新/删除、设置为NULL等）主动处理相关子表的数据。
    
  • 简化开发：减少了应用步调层面对于维护关系完备性的负担，由于这些规则已经在数据库级别得到了保障。
    
  
  
• 缺点：
  
  
  
  • 性能影响：由于每次插入、更新或删除操纵都需要检查外键束缚，这可能会带来一定的性能开销，尤其是在大规模数据集上。
    
  • 灵活性低落：一旦设置了物理外键，修改或移除这种束缚可能需要更多的步调，并且可能会影响到现有应用的功能。
    
  • 锁定问题：在高并发情况下，对外键的检查可能导致行锁或表锁，进而影响体系的响应速度。
    
  
  

逻辑外键（Logical Foreign Key）

• 定义：逻辑外键不是由数据库体系直接管理的一种约定，而是通过应用步调代码或者业务逻辑来模仿外键举动。这意味着并没有实际的外键束缚存在于数据库模式中。
  
• 长处：
  
  
  
  • 更高的灵活性：可以更自由地改变数据模型而不必担心破坏现有的外键关系。
    
  • 减少性能消耗：没有额外的束缚检查，理论上可以提高某些操纵的速度。
    
  • 适用于跨数据库情况：当涉及到多个数据库之间的关联时，逻辑外键可能是唯一可行的选择。
    
  
  
• 缺点：
  
  
  
  • 缺乏内置支持：必须依靠应用步调逻辑来保证数据的同等性，增加了堕落的风险。
    
  • 复杂度增加：开发者需要自己编写代码来处理全部与外键相关的规则，包罗级联更新、删除等操纵，增加了开发和维护的工作量。
    
  • 难以追踪错误：假如违反了所谓的“逻辑外键”规则，错误可能不会立即显现出来，直到出现问题后才被发现。
    
  
  

总结

选择使用物理外键还是逻辑外键取决于具体的需求和技术栈：

• 假如强调数据同等性和完备性，并且对性能的影响是可以接受的，那么应该优先考虑使用物理外键。
  
• 假如追求更高的灵活性和性能，或者是面对复杂的多数据库集成情况，则可以考虑采取逻辑外键的方式，但同时需要注意增强应用步调级别的验证和控制以补充缺失的数据库级束缚。
  

9、MySQL 事务的二阶段提交是什么？ 中等

在MySQL中，尤其是在使用InnoDB存储引擎时，**二阶段提交（Two-Phase Commit, 2PC）**是分布式事务管理中的一个关键机制。它确保了全部参与节点要么都成功提交事务，要么都回滚事务，从而保持数据的同等性。二阶段提交过程分为两个阶段：准备阶段（Prepare Phase）和提交阶段（Commit Phase）。下面是每个阶段的具体阐明：
准备阶段（Prepare Phase）

• 协调者发送准备请求：事务协调者向全部参与者发送PREPARE下令，扣问它们是否准备好提交事务。
  
• 参与者响应：
  
  
  
  • 假如参与者可以或许成功完成其本地部分的事务处理，并且有信心可以在后续阶段正式提交，则返回“准备停当”（Prepared）的状态给协调者。
    
  • 假如任何一个参与者无法完成其工作或不确认能否提交，则返回“未准备”（Not Prepared）状态。
    
  
  

在这个阶段，假如全部的参与者都返回了“准备停当”的状态，那么整个事务就被认为是可以安全提交的；假如有任何一个参与者报告失败，则整个事务会被回滚。
提交阶段（Commit Phase）

根据准备阶段的结果，提交阶段会有两种不同的路径：
成功路径

• 协调者决定提交：当全部参与者都回复了“准备停当”，协调者会做出最终决议——提交事务。
  
• 协调者发送提交请求：协调者向全部参与者发送COMMIT下令。
  
• 参与者实验提交：每个参与者汲取到COMMIT下令后，正式提交自己的本地事务，并向协调者确认已完成提交。
  
• 协调者记录日志并结束事务：一旦全部参与者都成功提交，协调者将此次操纵记录到持久化日志中，并通知全部参与者事务已经成功结束。
  

失败路径

• 协调者决定回滚：假如有任何一个参与者在准备阶段报告了“未准备”，或者协调者自己遇到了问题，它就会选择回滚事务。
  
• 协调者发送回滚请求：协调者向全部参与者发送ROLLBACK下令。
  
• 参与者实验回滚：每个参与者汲取到ROLLBACK下令后，撤销之前所做的任何更改，并向协调者确认已完成回滚。
  
• 协调者记录日志并结束事务：协调者同样需要记录此次回滚操纵的日志，并告知全部参与者事务已终止。
  

为什么需要二阶段提交？

二阶段提交的主要目的是为了保证分布式体系中多个节点之间的数据同等性。通过这种方式，纵然某个节点发生了故障，只要其他节点都可以或许正常运作，就可以保证事务要么全部提交，要么全部回滚，制止了部分提交导致的数据不同等问题。
然而，二阶段提交也带来了额外的复杂性和性能开销，由于它要责备部参与者都要等候协调者的指示才能继续进步，这可能会成为体系的瓶颈。别的，假如协调者出现故障，整个事务可能会陷入不确定的状态，直到协调者恢复为止。因此，在设计分布式体系时，需要权衡使用二阶段提交所带来的利益与潜在的风险。
对于单个数据库实例内的事务，MySQL/InnoDB并不需要显式的二阶段提交流程，由于它是基于ACID特性的单节点事务管理体系。但在涉及多个数据库实例或跨服务的分布式事务场景下，二阶段提交就是一个必要的机制。
10、MySQL 为什么使用 B+ ？

MySQL的InnoDB存储引擎选择使用B+树（B Plus Tree）作为其索引结构，主要是由于B+树在数据库操纵中提供了良好的性能和特性。以下是B+树相对于其他数据结构的上风，以及它为什么得当用作MySQL索引的缘故原由：
1. 高效的磁盘访问

• 减少I/O次数：B+树设计为可以或许有效地使用磁盘块（或页），每个节点可以包罗多个键值对，并且通常一个节点的巨细与磁盘块相匹配。这意味着每次磁盘读写操纵都可以获取尽可能多的数据，从而减少了所需的I/O次数。
  
• 次序扫描友好：全部叶子节点都通过指针链接在一起，形成了一个双向链表，这使得范围查询（如SELECT * FROM table WHERE key BETWEEN value1 AND value2）可以高效地举行次序扫描。
  

2. 精良的并发性

• 行级锁支持：由于B+树的全部记录都位于叶子节点上，而内部节点只存储用于导航的键，因此可以在不影响其他部分的情况下对单个记录加锁，提高了并发处理本事。
  

3. 平衡性保证

• 高度平衡：B+树是一种自平衡的树形结构，无论插入或删除操纵如何频繁，树的高度始终保持在一个较低水平，确保了查找、插入和删除等操纵的时间复杂度稳定为O(log n)。
  

4. 空间使用率高

• 紧凑的存储：相比于B树，B+树将全部实际数据项都放在叶子节点中，非叶子节点仅保存用于搜刮的键，这样不仅节省了空间，而且有利于提高缓存掷中率。
  

5. 优化了范围查询

• 一连存储：在B+树中，雷同范围内的数据会尽量被存储在同一页面内或者相邻页面上，这对于需要遍历一系列一连记录的操纵非常有利。
  

6. 简化维护

• 易于分裂和合并：当节点中的元素过多时，B+树可以通过简朴地分裂成两个节点来保持树的平衡；相反地，当节点变得过于稀疏时，也可以轻松地与其他节点合并。这种机制简化了树的维护工作。
  

综上所述，B+树因其精彩的磁盘访问服从、精良的并发性和空间使用率等特点，成为MySQL InnoDB存储引擎理想的索引结构。别的，它还特别适用于OLTP（在线事务处理）体系，这类体系要求快速响应时间、高并发处理本事和高效的数据检索。
11、MySQL 三层 B+ 树能存多少数据？ 中等

在MySQL的InnoDB存储引擎中，三层B+树可以存储的数据量取决于多种因素，包罗但不限于页巨细、主键类型（如INT或BIGINT）、行数据的实际巨细等。根据已有资料，我们可以得出以下结论：

• 对于主键为 BIGINT 的情况：假设一页巨细为16KB，默认情况下，一个非叶子节点可以存放约莫1170个“主键+指针”的组合（每个组合占用约14字节）。因此，在这种设定下，三层B+树可以存储约莫21,902,400条记录。
  
  
  
  • 盘算公式为：(1170 \times 1170 \times 16 = 21,902,400) 条记录
    
  
  
• 对于主键为 INT 的情况：同样地，假如一页巨细为16KB，那么一个非叶子节点可以存放约莫1600个“主键+指针”的组合（每个组合占用约10字节）。在这种设定下，三层B+树可以存储约莫40,960,000条记录。
  
  
  
  • 盘算公式为：(1600 \times 1600 \times 16 = 40,960,000) 条记录
    
  
  

需要注意的是，上述盘算是基于理想化的假设条件，实际情况中可能会由于行格式、填充因子、是否存在额外索引等因素而有所不同。别的，随着数据库版本和技术的发展，这些参数也可能发生变革。因此，在评估具体应用时，建议参考最新的官方文档和现真相况举行测试与验证。
12、MySQL 在设计表（建表）时需要注意什么？ 中等

在设计MySQL表（即建表）时，需要考虑多个方面以确保数据库的性能、可维护性和数据完备性。以下是设计MySQL表时应关注的一些关键点：
1. 明白需求和规划

• 业务明白：深入了解业务逻辑和数据模型，确保设计满意实际应用的需求。
  
• 规模预测：预估将来几年的数据增长趋势，为表结构预留足够的扩展空间。
  

2. 选择合适的数据类型

• 最小化存储空间：选用最紧凑的数据类型来表示数据，如使用TINYINT取代INT，除非确实需要更大的范围。
  
• 制止冗余：不要为同一信息定义多个字段，减少不必要的数据重复。
  

3. 主键设计

• 唯一标识：每个表应该有一个或一组字段作为主键，用来唯一标识每一条记录。
  
• 自增ID vs UUID：根据应用场景选择合适的主键生成方式，例如AUTO_INCREMENT整数型主键得当大多数情况，而UUID则适用于分布式体系或多租户情况。
  

4. 索引策略

• 创建必要的索引：基于查询模式分析，对频繁出现在WHERE子句中的列建立索引，提高查询服从。
  
• 制止过分索引：过多的索引会增加写入操纵的本钱，并占用额外的存储空间。
  
• 覆盖索引：假如某个查询只需要访问索引中包罗的列，则可以构建覆盖索引以加速速度。
  

5. 外键束缚

• 参照完备性：公道使用外键束缚来维护不同表之间的关系，保证数据的同等性。
  
• 性能权衡：固然外键有助于防止孤立记录的存在，但在高并发写入场景下可能会带来性能开销，需谨慎评估是否启用。
  

6. 分区与分片

• 水平分区（Sharding）：对于非常大的表，可以考虑按某种规则将数据分散到多个物理表或服务器上，减轻单个实例的压力。
  
• 垂直分区（Partitioning）：把不常用的列拆分出去形成新的表，优化常用查询路径。
  

7. 默认值和非空限制

• 设置公道的默认值：对于某些字段，提供故意义的默认值可以帮助简化插入操纵。
  
• 逼迫非空检查：通过NOT NULL束缚确保重要字段不会出现空值，从而保护数据质量。
  

8. 字符集和排序规则

• 统一字符集：选择一个得当你应用的字符集（如UTF-8），并保持整个数据库的同等性。
  
• 排序规则（Collation）：根据语言和地区风俗选择适当的排序规则，影响字符串比力的结果。
  

9. 触发器和存储过程

• 适度使用：尽管触发器和存储过程可以在一定程度上简化业务逻辑，但它们也可能增加体系的复杂度，应该只在必要时使用。
  

10. 文档息争释

• 编写清晰的解释：为表结构添加解释，阐明各字段的意义及其取值范围，便于后续维护。
  
• 维护变更日志：记录每一次重要的结构修改，方便追溯历史版本。
  

11. 安全性和权限管理

• 最小权限原则：按照最小权限原则分配用户权限，确保只有授权职员才能实验特定的操纵。
  
• 敏感数据保护：对于涉及个人隐私或其他敏感信息的字段，采取加密等步调加以保护。
  

遵循上述引导原则举行表设计，不仅可以或许提升数据库的团体性能，还能增强其稳定性和安全性。固然，具体的设计还需要联合项目的现真相况灵活调整。
13、MySQL 插入一条 SQL 语句，redo log 记录的是什么？ 中等

在MySQL的InnoDB存储引擎中，当实验一条INSERT语句时，Redo Log（重做日志）记录的是与该插入操纵相关的物理级别的变更信息。具体来说，Redo Log会记录以下内容：
1. 页面分配

• 假如插入操纵导致需要分配新的数据页（Page），那么Redo Log会记录新页的分配情况。这包罗了页号、页类型等元数据。
  

2. 行记录的变革

• 插入操纵会在某个特定的数据页中添加一行新的记录。Redo Log会具体记录这一变革，包罗但不限于：
  
  
  
  • 行位置：即新增行在页中的偏移量。
    
  • 行内容：完备的行数据，或者至少是那些被修改或增加的字段值。
    
  • 记录头信息：例如事务ID、回滚指针等辅助信息，这些对于MVCC（多版本并发控制）和崩溃恢复非常重要。
    
  
  

3. 索引更新

• 每次插入新行时，除了数据自己外，相关的二级索引也需要更新。因此，Redo Log还会记录全部受影响的索引页上的变更，确保在崩溃恢复期间可以或许重建正确的索引结构。
  

4. 其他元数据变更

• 在某些情况下，可能还会涉及到对段（Segment）、区（Extent）或其他高层级存储结构的调整，这些变动同样会被记录到Redo Log中。
  

Redo Log的作用

Redo Log的主要作用是在体系发生故障后，可以通过重放这些日志条目来恢复未完成的事务，保证数据库的同等性和持久性。换句话说，纵然服务器突然断电或崩溃，只要Redo Log完好无损，就可以使用它来恢复到最近的一个同等点。
写入过程

• 当INSERT语句被实验时，相应的变更首先写入内存中的缓冲池（Buffer Pool），同时将形貌这些变更的日志条目追加到Redo Log Buffer中。
  
• 然后，根据配置（如innodb_flush_log_at_trx_commit参数），定期地或在每次事务提交时，Redo Log Buffer中的内容会被刷写到磁盘上的Redo Log文件。
  
• 最终，在适当的机遇，脏页（Dirty Pages）也会从缓冲池革新到磁盘上的实际数据文件中。
  

总之，Redo Log记录的是与INSERT操纵有关的全部物理层面的具体更改，确保纵然在最坏的情况下也能准确地恢复数据库状态。这种机制是实现ACID特性的关键组成部分之一，特别是对于持久性和原子性的保障。
14、MySQL 的基本数据类型有哪些？

MySQL提供了多种基本数据类型，用于定义表中列的数据种类。以下是MySQL中常用的基本数据类型分类及其具体类型：
1. 数值类型

• 整数类型：
  
  
  
  • TINYINT：非常小的整数，范围为-128到127（有符号）或0到255（无符号）。
    
  • SMALLINT：小整数，范围为-32,768到32,767（有符号）或0到65,535（无符号）。
    
  • MEDIUMINT：中等巨细的整数，范围为-8,388,608到8,388,607（有符号）或0到16,777,215（无符号）。
    
  • INT 或 INTEGER：标准整数，范围为-2^31 (-2,147,483,648) 到 2^31 - 1 (2,147,483,647)（有符号）或0到2^32 - 1 (4,294,967,295)（无符号）。
    
  • BIGINT：大整数，范围为-2^63 (-9,223,372,036,854,775,808) 到 2^63 - 1 (9,223,372,036,854,775,807)（有符号）或0到2^64 - 1 (18,446,744,073,709,551,615)（无符号）。
    
  
  
• 浮点类型：
  
  
  
  • FLOAT(M,D)：单精度浮点数，通常占用4个字节。
    
  • DOUBLE(M,D) 或 DOUBLE PRECISION(M,D)：双精度浮点数，通常占用8个字节。
    
  
  
• 定点类型：
  
  
  
  • DECIMAL(M,D) 或 NUMERIC(M,D)：定点数，M是总位数，D是小数点后的位数。它确保了准确的小数表示。
    
  
  

2. 字符串类型

• 定长和变长字符串：
  
  
  
  • CHAR(N)：固定长度字符串，最大长度为255个字符。
    
  • VARCHAR(N)：可变长度字符串，最大长度可达65,535个字符（取决于行中其他列的巨细）。
    
  
  
• 文本类型：
  
  
  
  • TINYTEXT：最大长度为255个字符的文本。
    
  • TEXT：最大长度为65,535个字符的文本。
    
  • MEDIUMTEXT：最大长度为16,777,215个字符的文本。
    
  • LONGTEXT：最大长度为4,294,967,295个字符的文本。
    
  
  
• 二进制字符串类型：
  
  
  
  • BINARY(N) 和 VARBINARY(N)：类似于CHAR和VARCHAR，但存储的是二进制数据。
    
  
  
• 枚举类型：
  
  
  
  • ENUM('value1','value2',...)：答应在列中存储预定义的一组值中的一个。
    
  
  
• 聚集类型：
  
  
  
  • SET('value1','value2',...)：可以包罗多个来自预定义列表的值。
    
  
  

3. 日期和时间类型

• DATE：只存储日期部分，格式为YYYY-MM-DD。
  
• TIME：只存储时间部分，格式为HH:MM:SS或扩展的时间值。
  
• DATETIME：同时存储日期和时间，格式为YYYY-MM-DD HH:MM:SS，支持的范围从1000年到9999年。
  
• TIMESTAMP：也存储日期和时间，但是具有特定的时间戳特性，默认情况下主动记录创建时间和更新时间，并且与体系时区有关联。
  
• YEAR：专门用于存储年份信息，有两种格式：YEAR(2)（两位数年份）和YEAR(4)（四位数年份），默认是后者。
  

4. JSON 类型

• JSON：自MySQL 5.7版本起引入，用于存储有效的JSON文档。
  

5. 空间数据类型

• GEOMETRY、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTION：这些类型用于地理信息体系（GIS）应用，支持各种几何对象的存储。
  

选择合适的数据类型对于优化存储空间、查询性能以及确保数据完备性至关重要。在设计数据库表结构时，应根据实际需求来决定使用哪种数据类型。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。