MySQL数据库开发常见问题及几点优化！
|
MySQL数据库是被广泛应用的关系型数据库，其体积小、支持多处理器、开源并免费的特性使其在Internet中小型网站中的使用率尤其高。在使用 MySQL的过程中不规范的SQL编写、非最优的策略选择都可能导致系统性能甚至功能上的缺陷。 恰巧就在前几天，本人所在公司的云事业部举办了一场关于MySQL的技术交流会，其中一个部分正是聚焦于开发过程中MySQL数据库设计及使用的常见问题，并提出相关优化方案。根据会议内容并查阅相关资料，本人对这个部分进行了一次小结，结合自己的工作经历及理解形成此文以供分享，希望能有助于各位同行解决工作中的相关问题。 本文将就以下三个问题进行展开： 一、库表设计1.1、引擎选择 在 MySQL5.1 中，引入了新的插件式存储引擎体系结构，允许将存储引擎加载到正在运新的 MySQL服务器中。使用 MySQL插件式存储引擎体系结构，允许数据库专业人员或者设计库表的软件开发人员为特定的应用需求选择专门的存储引擎，完全不需要管理任何特殊的应用编码要求，也无需考虑所有的底层实施细节。因此，尽管不同的存储引擎具有不同的能力，应用程序是与之分离的。此外，使用者可以在服务器、数据库和表格三个层级中存储引擎，提供了极大的灵活性。 MySQL常用的存储引擎包括 MyISAM、InnoDB 和 Memory，其中各自的特点如下： MyISAM: 全表锁，拥有较高的执行速度，一个写请求请阻塞另外相同表格的所有读写请求，并发性能差，占用空间相对较小，MySQL5.5 及以下仅 MyISAM支持全文索引，不支持事务。 InnoDB：行级锁（SQL 都走索引查询），并发能力相对强，占用空间是 MyISAM的 2.5 倍，不支持全文索引（5.6 开始支持），支持事务。 Memory : 全表锁，存储在内存当中，速度快，但会占用和数据量成正比的内存空间且数据在 MySQL重启时会丢失。 基于以上特性，建议绝大部份都设置为InnoDB引擎，特殊的业务再考虑选用MyISAM或 Memory ，如全文索引支持或极高的执行效率等。 1.2、分表方法
在数据库表使用过程中，为了减小数据库服务器的负担、缩短查询时间mysql数据表，常常会考虑做分表设计。分表分两种，一种是纵向分表（将本来可以在同一个表的内容，人为划分存储在为多个不同结构的表）和横向分表（把大的表结构，横向切割为同样结构的不同表）。 其中，纵向分表常见的方式有根据活跃度分表、根据重要性分表等。其主要解决问题如下： 横向分表是指根据某些特定的规则来划分大数据量表，如根据时间分表。其主要解决问题如下： 1.3、索引问题 索引是对数据库表中一个或多个列的值进行排序的结构，建立索引有助于更快地获取信息。 mysql 有四种不同的索引类型： 建立索引的目的是加快对表中记录的查找或排序，索引也并非越多越好，因为创建索引是要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间维护索引。 在设计表或索引时，常出现以下几个问题： 二、慢 SQL 问题2.1、导致慢 SQL 的原因 在遇到慢 SQL 情况时，不能简单的把原因归结为 SQL 编写问题(虽然这是最常见的因素)，实际上导致慢 SQL 有很多因素，甚至包括硬件和 MySQL本身的Bug。根据出现的概率从大到小，罗列如下： 2.2、由 SQL 编写导致的慢 SQL 优化 针对SQL编写导致的慢 SQL，优化起来还是相对比较方便的。正如上一节提到的正确的使用索引能加快查询速度，那么我们在编写 SQL 时就需要注意与索引相关的规则： 除了上述索引使用规则外，SQL 编写时还需要特别注意一下几点： 三、分析诊断工具 在日常开发工作中，我们可以做一些工作达到预防慢 SQL 问题，比如在上线前预先用诊断工具对 SQL 进行分析。常用的工具有： 具体使用及分析方法在此就不赘述，网上有丰富的资源可以参考。 四、误操作、程序 bug 时怎么办 提出这个问题显然主要是针对刚开始工作的年轻同行们……实际上误操作和程序 bug 导致数据误删或者混乱的问题并非少见，但是刚入行的开发工作者会比较紧张。一个成熟的企业往往会有完善的数据管理规范和较丰富的数据恢复方案（初创公司除外），会进行数据备份和数据容灾。当你发现误操作或程序 bug 导致线上数据被误删或误改动时，一定不能慌乱，应及时与 DBA 联系，第一时间进行数据恢复（严重时直接停止服务），尽可能减少影响和损失。对于重要数据（如资金）的操作，在开发时一定要反复进行测试，确保没有问题后再上线。 PS：如果觉得我的分享不错，欢迎大家随手点赞、转发。 （完）
Java团长 （编辑：武陵站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
