DDR爱好者之家 Design By 杰米
一、两表之间若有关联，你是否还在用主键进行关联？
比如现在有2张表，一张新闻栏目表，一张新闻表，现在两张表需要进行关联，我想大多数人的做法肯定是在新闻表里建一个新闻栏目id，然后把新闻栏目表里的主键ID（自增）写到这个字段里，通过这样进行两表关联。
如果你是这样做的，赶紧改掉这个习惯吧。也许你会问为什么，栏目id是主键啊，又是自增的，为什么这样操作不行？原因其实很简单，栏目我们会增加，也会删除，删除就会造成主键id之间会有断号的情况，由于主键设置为自增，也就是说你之前删掉的栏目，再进行添加，id是不会去补上哪个空缺的，而是一直递增。这样就会造成一种情况，如果那天对数据库进行优化，把主键进行了重新排序（暂时没有找到mysql优化软件会优化主键，但是可以通过代码删除主键，然后从新建立自增主键来实现主键重新排序），那就彻底杯具了，栏目和文章完全对不上号了。所以我建议两表之间关联不用主键，而是单独建一个编号的字段，我们这里可以用mysql的uuid()函数做为编号，相关文献可以参考《UUID做主键好还是不好》，只所以一张表要2个主键，一个物理主键（自增id），一个逻辑主键（UUID），原因是：对于InnoDB这种聚集主键类型的引擎来说，数据会按照主键进行排序，由于UUID的无序性，InnoDB会产生巨大的IO压力，此时不适合使用UUID做物理主键，可以把它作为逻辑主键，物理主键依然使用自增ID。至于性能，我本地测了下基本上没差异，网上也有人做了10W条数据的测试——《实测MYSQL UUID性能》。
二、统一把主键类型设为bigint吧
bigint是从-2^63 (-9223372036854775808)到2^63-1 (9223372036854775807)的所有整型数据，存储大小为8个字节。而int是从-2^31 (-2,147,483,648)到2^31-1 (2,147,483,647)的整型数据，存储大小为4个字节。存储空间扩大一倍，而存储数据却扩大N倍，再加上主键是一个自增的字段，我们根本无法控制它会自增到多少数值，所以我通常在建表的时候，主键类型都是设为bigint的，同样，上面提到的编号字段类型也是bigint。
三、不要把varchar长度设太“死”
这也是我之前经常犯得一个毛病，比如手机，我就设置为varchar(11)，邮编设置成varchar(6)，姓名设置成varchar(10)等等等等，看似每个字段都设置得很严谨，但是在项目实际进行中，这完全就是自找苦吃，比如手机，用户偏偏就要在手机号前输个0，又比如邮编，如果用户输入的是全角的数字呢？姓名就更不用说了，万一是个少数民族的人，名字七八个字。所以我建议，既然定义为varchar，就代表不会涉及到计算，何不干脆定义一个通用的长度，比如varchar(50)，如果真要限制长度，用程序去判断，不要让数据库来限制，不然用户输了一长串，结果mysql就存了前几个字符，让人觉得这程序有问题。
还有就是，如果你是做cms这种通用后台，更别把字段限制得太“死”，因为你无法预料之后的每个项目的需求，所以还是把varchar设大一点，我现在是统一都设为255，如果很有可能会超过255的字段，比如URL，我就干脆设置成text，一劳永逸。
四、为常用的搜索字段建立索引吧
不解释，但不要盲目建立索引。
五、欢迎您的回复补充
比如现在有2张表，一张新闻栏目表，一张新闻表，现在两张表需要进行关联，我想大多数人的做法肯定是在新闻表里建一个新闻栏目id，然后把新闻栏目表里的主键ID（自增）写到这个字段里，通过这样进行两表关联。
如果你是这样做的，赶紧改掉这个习惯吧。也许你会问为什么，栏目id是主键啊，又是自增的，为什么这样操作不行？原因其实很简单，栏目我们会增加，也会删除，删除就会造成主键id之间会有断号的情况，由于主键设置为自增，也就是说你之前删掉的栏目，再进行添加，id是不会去补上哪个空缺的，而是一直递增。这样就会造成一种情况，如果那天对数据库进行优化，把主键进行了重新排序（暂时没有找到mysql优化软件会优化主键，但是可以通过代码删除主键，然后从新建立自增主键来实现主键重新排序），那就彻底杯具了，栏目和文章完全对不上号了。所以我建议两表之间关联不用主键，而是单独建一个编号的字段，我们这里可以用mysql的uuid()函数做为编号，相关文献可以参考《UUID做主键好还是不好》，只所以一张表要2个主键，一个物理主键（自增id），一个逻辑主键（UUID），原因是：对于InnoDB这种聚集主键类型的引擎来说，数据会按照主键进行排序，由于UUID的无序性，InnoDB会产生巨大的IO压力，此时不适合使用UUID做物理主键，可以把它作为逻辑主键，物理主键依然使用自增ID。至于性能，我本地测了下基本上没差异，网上也有人做了10W条数据的测试——《实测MYSQL UUID性能》。
二、统一把主键类型设为bigint吧
bigint是从-2^63 (-9223372036854775808)到2^63-1 (9223372036854775807)的所有整型数据，存储大小为8个字节。而int是从-2^31 (-2,147,483,648)到2^31-1 (2,147,483,647)的整型数据，存储大小为4个字节。存储空间扩大一倍，而存储数据却扩大N倍，再加上主键是一个自增的字段，我们根本无法控制它会自增到多少数值，所以我通常在建表的时候，主键类型都是设为bigint的，同样，上面提到的编号字段类型也是bigint。
三、不要把varchar长度设太“死”
这也是我之前经常犯得一个毛病，比如手机，我就设置为varchar(11)，邮编设置成varchar(6)，姓名设置成varchar(10)等等等等，看似每个字段都设置得很严谨，但是在项目实际进行中，这完全就是自找苦吃，比如手机，用户偏偏就要在手机号前输个0，又比如邮编，如果用户输入的是全角的数字呢？姓名就更不用说了，万一是个少数民族的人，名字七八个字。所以我建议，既然定义为varchar，就代表不会涉及到计算，何不干脆定义一个通用的长度，比如varchar(50)，如果真要限制长度，用程序去判断，不要让数据库来限制，不然用户输了一长串，结果mysql就存了前几个字符，让人觉得这程序有问题。
还有就是，如果你是做cms这种通用后台，更别把字段限制得太“死”，因为你无法预料之后的每个项目的需求，所以还是把varchar设大一点，我现在是统一都设为255，如果很有可能会超过255的字段，比如URL，我就干脆设置成text，一劳永逸。
四、为常用的搜索字段建立索引吧
不解释，但不要盲目建立索引。
五、欢迎您的回复补充
DDR爱好者之家 Design By 杰米
广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
DDR爱好者之家 Design By 杰米
暂无评论...
RTX 5090要首发 性能要翻倍！三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB，每个模块容量为2GB。其速度预设为32 Gbps（PAM3），但也可以降至28 Gbps，以提高产量和初始阶段的整体性能和成本效益。
据三星表示，GDDR7内存的能效将提高20%，同时工作电压仅为1.1V，低于标准的1.2V。通过采用更新的封装材料和优化的电路设计，使得在高速运行时的发热量降低，GDDR7的热阻比GDDR6降低了70%。
更新日志
2024年12月28日
2024年12月28日
- 小骆驼-《草原狼2(蓝光CD)》[原抓WAV+CUE]
- 群星《欢迎来到我身边 电影原声专辑》[320K/MP3][105.02MB]
- 群星《欢迎来到我身边 电影原声专辑》[FLAC/分轨][480.9MB]
- 雷婷《梦里蓝天HQⅡ》 2023头版限量编号低速原抓[WAV+CUE][463M]
- 群星《2024好听新歌42》AI调整音效【WAV分轨】
- 王思雨-《思念陪着鸿雁飞》WAV
- 王思雨《喜马拉雅HQ》头版限量编号[WAV+CUE]
- 李健《无时无刻》[WAV+CUE][590M]
- 陈奕迅《酝酿》[WAV分轨][502M]
- 卓依婷《化蝶》2CD[WAV+CUE][1.1G]
- 群星《吉他王(黑胶CD)》[WAV+CUE]
- 齐秦《穿乐(穿越)》[WAV+CUE]
- 发烧珍品《数位CD音响测试-动向效果（九）》【WAV+CUE】
- 邝美云《邝美云精装歌集》[DSF][1.6G]
- 吕方《爱一回伤一回》[WAV+CUE][454M]