世界上本没有程序员老鸟，菜鸟踩的坑多了也就成了老鸟。程序员
菜鸟：我看到项目里面使用的主键类型是UUID，使用Long类型的自增很差嘛？web
老鸟：你先理出Long类型的自增ID的优势。数据库
菜鸟：自增Long类型的主键能够主键自增，数字类型占用空间小，走索引速度更快，对于排序有更好的性能，不用担忧重复的问题，在程序中使用起来更方便。架构
老鸟：那你说一说UUID的缺点。svg
菜鸟：UUID占用内存空间大，索引相对来说慢一些，数据量大了可能会重复，不易排序，在程序中使用也不是很方便。心里一阵窃喜，这不明摆着就该使用Long类型的自增主键嘛，嘿嘿！！！微服务
老鸟：小伙子能够呀，总结的还不错嘛，嗯。。。 but 。。。性能
菜鸟：内心一阵很差的预感。。。xml
老鸟：刚才你说的都对，可是你没有结合项目自己考虑。咱们考虑如下状况：假如咱们须要手动插入，或者从其余系统导入带有id的数据，这些数据的id和原来数据的id冲突了怎么办，而且这些数据也是数值型的？排序
菜鸟：这个。。。这个。。。（这就涉及到个人知识盲区了）。索引
老大鸟：还有啊，若是新系统上线运行，旧系统同时运行，数据库异构，而且数据双向同步，这个时候若是id有冲突怎么办？
菜鸟：。。。
老鸟：如果从外面导入数据，咱们须要区别，须要将id前面加一个符号区分，这个时候又该怎么办？
菜鸟：卒！！！
老鸟：还有呢，在作系统集成的时候，若是新系统的主键不是数字类型的，那么就会考虑修改旧系统的主键类型，那么关联的外键如何处理呢？
菜鸟：弱小。。。无助。。。哭。。。
老鸟：小伙子，懂了吧，仍是要多磨练呀，将书本知识与实际结合才是硬道理呀。
菜鸟：受教了，受教了！！！
其实UUID和自增型的数值ID各有个的有点与缺点，没有哪种更好，只有哪种更合适，通常来说自增主键ID更适合用于单机系统，性能方面确实要优于UUID，可是在微服务架构，多系统集成的时候，通常建议使用UUID，不是说UUID在微服务架构的效率表现更高，而是说能够避免主键自增ID的一些缺陷。
使用场景：
我的感觉：
在菜鸟们才开始步入工做岗位的时候，不免会遇到不少问题，这个时候就须要老鸟们的帮助了，毕竟他们踩过的坑比咱们写过的代码还多，向他们寻求帮助是最好的提升本身的方式，当你踩过了全部的坑，你就是老鸟中的大神。