本篇内容主要讲解“MySQL的表设计与使用”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MYSQL的表设计与使用”吧!
创新互联公司-专业网站定制、快速模板网站建设、高性价比佳县网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式佳县网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖佳县地区。费用合理售后完善，十载实体公司更值得信赖。
一个表的设计，个人愚见，首先要看业务，以及你选择的架构，业务量是大还是小，业务是互联网性质的，还是传统性质的，业务是可变化较大的，还是比较固话的，等等，当然可能还有更细分的，从数据库的角度来看，你是准备使用哪种数据库，决定是可以分库分表，还是分区表，或者冷热表，在或者使用特殊的某些小手段，来让你的表更清爽一些。同时不同的数据库也赋予表设计更多的余地，所以我一直在希望开发和DBA能紧密结合，因为开发大部分是不知道各种数据库的门道，和一些奇特的功能，而DBA可能并未有开发人员的对业务理解的深刻，如果二者结合，则设计的表会比单方面设计的表要好的多。也更值得推敲。
下面就说说，在MYSQL 表设计中的一些见过的，小麻烦，以及如何化解。
1拿到的数据中，MYSQL的表竟然没有主键，根据和开发人员交流，发现他们有一个很有趣的想法，认为没有主键的表的插入速度会快，因为他们要要求插入的速度要快，而根据他们以往的ORACLE的经验是这样认为的。当时和他们解释，他们提出ORACLE的表没有主键会在表上默认产生ROWID，所以对这样的信息记录的表（弱业务）是可以这样设计的，先不提在ORACLE 这样是否OK，在MYSQL 中我只问了他们一个问题，“请问这个表还需要查询吗”，回答是当然。
根据他们的回答，我建议，既然要查询，则需要建立主键，或者退而求其次建立唯一索引。并解释了为什么(MYSQL的表的原理，以及底层结构），开发人员表示认同，随即添加主键。
其实之前也是遇到过这样的情况，但当时解释的角度就是一句，规章制度，军规，或者在解释MYSQL的复制必须要设置主键，等等。但开发人员给我的回馈是不是太好，这让当时我的反思，在解决问题的时候要站在对方的角度，来处理，对方会更好的接受和理解，并且还会和你一条心的解决，因为这设计了他自己的利益。
2 在参与一个系统的设计时，开发人员将一个表的主键设置为多个列，根据业务逻辑来看，他这样做是没有问题的，地区编码，加客户编码，加客户的类型，是能决定这个表中客户的唯一性，虽然从MYSQL本身的角度不建议这样做，但开发人员提出，那业务已经这样设计，你让我怎么办，这里面差一个字段，都不能确认具体的客户的唯一性，而且业务也没有打算给每一个客户分配一个唯一的编码。
到此即使你拿出军规，或者数据库原理来和开发讲，也是无效，他也是受害者。现在关键的问题是你怎么来化解这个事情，而不是强硬的创造“对立面”。
解决方法1 和开发人员商量，是否可以创建递增主键，按照INT 类型，而我们的区域，客户类型，以及客户ID，则作为唯一索引进行创建，开发人员表示可以考虑。
解决方法2 和开发人员商量，是否可以通过重新物理编码的方式，通过三个字段的值进行运算后得出一个唯一值，将这个值作为主键，并且计算值的时候可以考虑一下顺序性例如
区域+ 用户类型 + 用户ID +数据插入时间 （可以到秒）--根据输入的用户量与时间的之间的比率。并且在表的字段中加入数据插入的时间，这样虽然看上去比上面的方式麻烦，但可以解决查询时的唯一性，也不需要建立唯一索引，通过主键可快速定位相对应的用户。
最后的结果，开发选择了第二种方法，其实大部分DBA 都是拿出，规则，规矩来进行限制，当然这本身是对的，这也是为系统正常运行来考虑的，但如果稍微站在对方的角度，来处理，可能效果预期会更好。
3 在开发一个系统的时候，大部分开发人员之前是没有使用过MYSQL数据库的，在表结构的设计，虽然之前提及过的一些MYSQL 特有的规范，但还是在数据库的设计中发现了大量的主外键设计，随即和开发人员沟通，发现开发人员的想法还是在三范式,3NF,以及表之间关联性完整性，以及数据的不重复性考虑。后面和开发人员沟通，对当前使用的MYSQL的版本以及 Join 的MYSQL 操作原理进行了讲解，开发人员表示理解，后面和开发人员将原来的表设计重新梳理，将一些频繁查询的数据汇总到一张表，或两张表中，不在4-9张表进行JOIN 才能获得数据，同时也对开发人员在改变设计后的繁琐表示理解。
从沟通中也了解，程序员的想法，大多是根据3NF的影响，避免不同表中重复的字段，在查询中通过多个表的关联+条件，进行信息的输出，与互联网行业相比某些传统的行业的逻辑会比较复杂，所以使用MYSQL 会让程序在非数据库层做的更多，想的更多。这也是部分程序员吐槽MYSQL 数据库不好用的原因。
所以和在使用任何一种数据库的时候，前提要以服务业务为中心，基于所使用的数据库的原理进行发散，或混合行的思维方式，不能只死在一个数据库，例如如果频繁的更新状态，但一行记录或业务无论有多少次变化，但最后的变化的值是固定的，那是不是可以使用其他的数据库（非RDS）来进行快速的状态缓冲最终将结果刷入的到数据库表中，避免由于频繁更新和查询产生的性能问题，等等这都是需要开发和DBA 进行沟通，利用互有的知识进行，以达到最大的优化和将问题消灭在系统设计的初期。
所以，合作能共赢，而军规，规定等等都是一个范围，而如果在这个范围无法解决问题，则这个范围是不是有问题，或者我们是否还能更进一步的提高自己的能力，利用各种手段维护军规的同时，还能满足业务，开发的需求，这就要看个人的能力，你会的越多，你解决问题的高度就会更高。相关与你有关的对立面就越少。
到此，相信大家对“MYSQL的表设计与使用”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！