数据库的错误操作有哪些

这篇文章主要讲解了“数据库的错误操作有哪些”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“数据库的错误操作有哪些”吧！通常开发人员写好sql语句之后，习惯通过聊天工具，比如：qq、钉钉、或者腾讯通等，发给团队老大或者DBA在线上环境执行。但由于有些聊天工具，对部分特殊字符会自动转义，而且有些消息由于内容太长，会被自动分成多条消息。这样会导致团队老大或者DBA复制出来的sql不一定是正确的。他们需要手动拼接成一条完整的sql，有时甚至需要把转义后的字符替换回以前的特殊字符，无形之中会浪费很多额外的时间。即使最终sql拼接好了，真正执行sq免费主机域名l的人，心里一定很虚。所以，强烈建议你把要在线上执行的sql语句用邮件发过去，可以避免使用聊天工具的一些弊端，减少一些误操作的机会。而且有个存档，方便今后有问题的时候回溯原因。很多聊天工具只保留最近7天的历史记录，邮件会保留更久一些。别用聊天工具发sql语句!别用聊天工具发sql语句!别用聊天工具发sql语句!重要的事情说三遍，它真的能减少一些误操作。有些时候，开发人员写的sql语句很长，使用了各种join和union，而且使用美化工具，将一条sql变成了多行。在复制sql的时候，自己都无法确定sql是否完整。(为了装逼，把自己也坑了，哈哈哈)线上环境有时候需要通过命令行连接数据库，比如：mysql，你把sql语句复制过来后，在命令行界面执行，由于屏幕滚动太快，这时根本无法确定sql是否都执行成功。针对这类问题，强烈建议把sql语句压缩成一行，去掉多余的换行符和空格，可以有效的减少一些误操作。sql压缩工具推荐使用：https://tool.lu/sql/需要特别说明的是：本文的操作数据主要指修改和删除数据。很多时候，由于我们人为失误，把where条件写错了。但没有怎么仔细检查，就把sql语句直接执行了。影响范围小还好，如果影响几万、几十万，甚至几百万行数据，我们可能要哭了。针对这种情况，在操作数据之前，把sql先改成select count(*)语句，比如：改成：查一下该sql执行后影响的记录行数，做到自己心中有数。也给自己一次测试sql是否正确，确认是否执行的机会。即使通过上面的select语句确认了sql语句没有问题，执行后影响的记录行数是对的。也建议你不要立刻执行，建议在正在执行的时候，加上limit + select出的记录行数。例如：假设有一次性更新的数据太多，所有相关记录行都会被锁住，造成长时间的锁等待，而造成用户请求超时。此外，加limit可以避免一次性操作太多数据，对服务器的cpu造成影响。还有一个最重要的原因：加limit后，操作数据的影响范围是完全可控的。很多人写update语句时，如果要修改状态，就只更新状态，不管其他的字段。比如：这条sql会把status等于0的数据，全部更新成1。后来发现业务逻辑有问题，不应该这么更新，需要把status状态回滚。这时你可能会很自然想到这条sql：但仔细想想又有些不对。这样不是会把有部分以前status就是1的数据更新成0?这回真的要哭了，呜呜呜。这时，送你一个好习惯：在更新数据的时候，同时更新修改人和修改时间字段。这样在恢复数据时就能通过修改人和修改时间字段过滤数据了。后面需要用到的修改时间通过这条sql语句可以轻松找到：当然，如果是高并发系统不建议这种批量更新方式，可能会锁表一定时间，造成请求超时。有些同学可能会问：为什么要同时更新修改人，只更新修改时间不行吗?主要有如下的原因：为了标识非正常用户操作，方便后面统计和定位问题。有些情况下，在执行sql语句的过程中，正常用户产生数据的修改时间跟你的可能一模一样，导致回滚时数据查多了。在业务开发中，删除数据是必不可少的一种业务场景。有些人开发人员习惯将表设计成物理删除，根据主键只用一条delete语句就能轻松搞定。他们给出的理由是：节省数据库的存储空间。想法是好的，但是现实很残酷。如果有条极重要的数据删错了，想恢复怎么办?此时只剩八个字：没有数据，恢复不了。(PS：或许通过binlog二进制文件可以恢复)如果之前设计表的时候用的逻辑删除，上面的问题就变得好办了。删除数据时，只需update删除状态即可，例如：假如出现异常，要恢复数据，把该id的删除状态还原即可，例如：如果只是修改了少量的数据，或者只执行了一两条sql语句，通过上面的修改人和修改时间字段，在需要回滚时，能快速的定位到正确的数据。但是如果修改的记录行数很多，并且执行了多条sql，产生了很多修改时间。这时，你可能就要犯难了，没法一次性找出哪些数据需要回滚。为了解决这类问题，可以将表做备份。可以使用如下sql备份：先创建一张一模一样的表，然后把数据复制到新表中。也可以简化成一条sql：创建表的同时复制数据到新表中。此外，建议在表名中加上bak和时间，一方面是为了通过表名快速识别出哪些表是备份表，另一方面是为了备份多次时好做区分。因为有时需要执行多次sql才能把数据修复好，这种情况建议把表备份多次，如果出现异常，把数据回滚到最近的一次备份，可以节省很多重复操作的时间。恢复数据时，把sql语句改成select语句，先在备份库找出相关数据，每条数据对应一条update语句，还原到老表中。有时候，我们要先用一条sql查询出要更新的记录的id，然后通过这些id更新数据。批量更新之后，发现不对，要回滚数据。但由于有些数据已更新，此时使用相同的sql相同的条件，却查不出上次相同的id了。这时，我们开始慌了。针对这种情况，我们可以先将第一次查询的id存入一张临时表，然后通过临时表中的id作为查询条件更新数据。如果要恢复数据，只用通过临时表中的id作为查询条件更新数据即可。修改完，3天之后，如果没有出现问题，就可以把临时表删掉了。我们在写sql时为了方便，习惯性不带数据库名称。比如：假如有多个数据库中有相同的表order，表结构一模一样，只是数据不一样。由于执行sql语句的人一个小失误，进错数据库了。然后执行了这条sql语句，结果悲剧了。有个非常有效的预防这类问题的方法是加数据库名：这样即使执行sql语句前进错数据库了，也没什么影响。很多时候，我们少不了对表字段的操作，比如：新加、修改、删除字段，但每种情况都不一样。新加的字段一定要允许为空新加的字段一定要允许为空。为什么要这样设计呢?正常情况下，如果程序新加了字段，一般是先在数据库中加字段，然后再发程序的最新代码。为什么是这种顺序?因为如果先发程序，然后在数据库中加字段。在该程序刚部署成功，但数据库新字段还没来得及加的这段免费主机域名时间内，最新程序中，所有使用了新加字段的增删改查sql都会报字段不存在的异常。好了，就按先在数据库中加字段，再发程序的顺序。如果数据库中新加的字段非空，最新的程序还没发，线上跑的还是老代码，这时如果有insert操作，就会报字段不能为空的异常。因为新加的非空字段，老代码是没法赋值的。所以说新加的字段一定要允许为空。除此之外，这种设计更多的考虑是为了程序发布失败时的回滚操作。如果新加的字段允许为空，则可以不用回滚数据库，只需回滚代码即可，是不是很方便?删除字段是不允许的，特别是必填字段一定不能删除。为什么这么说?假设开发人员已经把程序改成不使用删除字段了，接下来如何部署呢?如果先把程序部署好了，还没来得及删除数据库相关表字段。当有insert请求时，由于数据库中该字段是必填的，会报必填字段不能为空的异常。如果先把数据库中相关表字段删了，程序还没来得及发。这时所有涉及该删除字段的增删改查，都会报字段不存在的异常。所以，线上环境必填字段一定不能删除的。修改字段要分为这三种情况：修改字段名称也不允许，跟删除必填字段的问题差不多。鸿蒙官方战略合作共建——HarmonyOS技术社区如果把程序部署好了，还没来得及修改数据库中表字段名称。这时所有涉及该字段的增删改查，都会报字段不存在的异常。如果先把数据库中字段名称改了，程序还没来得及发。这时所有涉及该字段的增删改查，同样也会报字段不存在的异常。所以，线上环境字段名称一定不要修改。修改字段类型时一定要兼容之前的数据。例如：tinyint改成int可以，但int改成tinyint要仔细衡量一下。varchar改成text可以，但text改成varchar要仔细衡量一下。字段长度建议改大，通常情况下，不建议改小。如果一定要改小，要先确认该字段可能会出现的最大长度，避免insert操作时出现字段太长的异常。此外，建议改大也需要设置一个合理的长度，避免数据库资源浪费。感谢各位的阅读，以上就是“数据库的错误操作有哪些”的内容了，经过本文的学习后，相信大家对数据库的错误操作有哪些这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是云技术，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: MySQL事务的概念以及事务隔离级别介绍

本篇内容主要讲解“MySQL事务的概念以及事务隔离级别介绍”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MySQL事务的概念以及事务隔离级别介绍”吧!先简单介绍一下MySQL中事务的概念，它是指：用于实现某种行为的…