数据库被标记可疑的解决方法

正准备吃晚饭，忽然接到客户电话，说收费软件无法连接后台服务器，于是赶紧打开电脑，远程连上客户电脑，下面就是数据库恢复过程，点击开始菜单， 打开数据库管理工具， 点击连接， 点击加号，展开数据库，数据库以显示为可疑，征询客户意见后，客户同意，直接从备份文件恢复，在数据库上点右键，点击删除， 点击确定，有问题的数据库就被删除了。现在我们来重新安装数据库，双击 d b setup， 选择网络 id 的 windows n t 方式登录，点击安装，安装完成， 双击打开收费管理软件， 从下拉列表中选择系统账号，输入密码，点击登录，点击 ok， 点击系统维护，点击数据恢复，找到自动备份的数据库文件， 向下拖动，找到最后一个辈分 文件，选中备份文件，点击恢复，点击确定，进行确认， 恢复成功，点击确定， 重新运行收费管理软件，输入用户名和密码登录， 点击在线监控 相机连接成功，视频画面显示出来了，车牌识别正常。至此，数据库恢复完成，可以安心吃饭了。请记得关注和点赞！

啊，一个长春的客户， cc 二零零五的数据库，两个分别质疑我们，经过处理成功搞定。感谢老铁支持啊。

客户自己把数据库误删了，然后去起诉开发程序员，我们公司真真实实的遇到过这件事情，就是整个项目上线了，那是一个公司的内部管理系统，一个 erp 系统啊，包含了整合了整个的公司流程啊，采购啊，财务啊什么都套进去了，然后上线了，没问题，已经运行了大概有三四个月左右，那个时候 客户就告诉我们数据全部都没了，我们就去找原因，找原因之后就发现部署在客户服务器里面的数据库 数据都空了，我不敢断提，到底是他们删的还是我们程序员删的吗？如果万一是我们开发删的呢？那肯定是我们的责任吗？那我就找每个开发全部都了解了一遍情况， 这个事情他们承诺真的都没有去去自己三四个月里面也没有 bug， 有，但是改 bug 阶段都是在那第一个月阶段改的比较多，会有一些 bug， 第二个阶段就很 少了，后面三四个月根本没碰，都没碰过这个服务器。我就去找到客户，我就跟他们老板打了个电话，意思就是让他去调查一下，看最近呢谁碰过这些服务器。同时呢，我让我们的开发也到对方的这个环境里面去查了，查了一下整个日字我们都会有做日字的， 查了日字之后发现有一个用户名，的确是客户那边的用户名，做了删除数据库的操作，对方调查结果出来之后就发现真的是他们自己把他误删了，并且不仅仅误删，他把备份也删掉了，这是个最重要的备份，只能到了我们开发交付的那一板 的那个地方有一个备份，是我们自己备份的，我们公司备份的，因为我们会有备份的机制，每七天会备份一次，防止这一些不小心的操作，所以我们只能把这个我们备份的东西放上去，那中间就会产生数据丢失，最终怎么解决呢？ 没办法，这种事情因为碰到的的确是比较少，概率比较小，误删的情况，我们就让对方把所有的数据对进入的数据啊都给我们，我们的人员一条一条给他录进去，录了挺久才录完， 全部还原回去，哪里有问题我们就找哪里，哪里有问题，开发也配合把数据改掉，这样才把整个事情把它搞定，才恢复到目前正常的数据。其实这因为这个录数据的过程啊，也耽误了他们两天，整个系统停工就等于两天有也有比较多损失了。从这一次事情之后啊，我都吸取了一个教训， 每一个客户上线了之后，我还会去安排我们的人员跟着背后去备份数据库，除非客户明确告诉我们，他不希望数据被我们备份，或者不希望数据 在他之外的所有人手里，这个时候我们才不会备份，并且会告知他，让他自己一定要去备份，并且这个备份你要锁一下，不要让大家任何人都能进去把备份删掉了，那就麻烦。

不要使用斯莱克的心！不要使用斯莱克的心！我相信这句话大家应该都不陌生，很多公司呢，也都会三令五申啊，严禁在代码中使用斯莱格的心， 就连这个阿里的加巴开发手册也明确表示不得使用新作为查询的这段列表。那么如果我在库乐瑞 vivo 中，如果发现有小伙伴啊这么写代码，我肯定不会让他过试用期 啊，不是说有多狠啊，这个是互联网社扣渔具的规则，关系到整个系统的性能，在很多的面子场合中也都会被问到， 那么为什么要这样呢啊，可能有些小伙伴会说啊，我们用三个星查的是所有字段，数据量大了，自然就会影响性能，这个呢是一个原因啊，我们都知道数据是存储在这个词盘上的啊，你去查所有的字段，肯定就会增加四盘 io 的 开销。如果这些字段中包含了一些大字段啊，比如说像 tx 呀，比如说像 blog 呀，对吧，那么读取呢，也会很慢啊。另外从这个应用服务器啊获取数据库服务器的数据本身呢，也会有一定的这个网络食言，查的越多啊，速度呢肯定就越慢 啊，查的慢啊，县城示范的就慢，就会影响其他的查询，县城自然呢，整体的性能就会受到影响。 还有一个原因就是你无法使用覆盖锁影，比如说你要查询的这段，碰巧设置了锁影，这时候呢，就可以直接从锁影的 b 加数中获取数据， 基于毕加数的解锁速度呢，还是很快的，但是这时候你偏偏用了随时的心啊，我们不可能说每个阶段都见缩影，对吧？那么自然呢，就没法直接从怂运术里面去查找数据，这时候呢，就得 从次盘上面去查找完整记录啊，这就是我们常说的回表，那么无法利用覆盖锁影了，那么在查询性能上面就打了折扣了。 其实换个思路想啊，我们为了提升性能，在前面达了很多的性能优化的策略，比如分工分秒啊，都限分离啊，结果你还用了三个星啊，这就像进了一个高楼大厦 啊，装修的很豪华，各种人性化的设计，结果呢，地基用的是泥糊的对吧，那么再去优化性能，再去怎么去啊？提高一些并发也都无济于事。好了，本期的视频呢，就是先来，如果您对本期的内容呢，有任何疑问，欢迎大家在评论区给我留言，谢谢大家！

奶奶个腿数据库被黑了咋办？

哦，原来你勒索我。是的，今天我们有个公网数字库被黑了， 对方留言勒索零点零零六比特币，按目前比特币的价值也就八百五十块人民币左右，还好平时有做数据库防范措施，通过 dbs 快速还原了数据，这次被黑并没有造成实际性的影响。 接下来分享一些数据库防范措施，大家有必要拿出小本子记下来。一、数据库密码使用大小写字母加数字加特殊符号的组合，密码长度八位以上。 二、每个库单独分配账号以及设置权限。三、项目税务库连接密码，使用加密方式进行连接。四、开启并 log。 五、使用税入库客户端或者是云服务商 dbs 进行备份，推荐使用 dbs。 六、如果是服务器上面之间的数据库，需开启服务器快照。七、如果是单独的数据库，需设置 ip 访问白名单。八、修改数据库默认端口，做好以上八点，你的数据库就不怕遭到黑客的攻击了。

你有没有这样的经历，就是自己在写代码的时候呢，感觉缩口执行非常快，然后程序的一个性能呢，也是杠杠的，但是没过几天发布到线上客户端呢，频繁报错，然后一看这个报错信息居然是后端的这个接口超时了啊，于是你就一脸问号，当时我查数据库明明挺快的呀， ok， 哈喽，大家好，我是于峰，欢迎大家看明视频。那么今天呢，我们就一起来分享几个 sucle 性能优化的小技巧啊，我今天所提到的这些小技巧呢，都是非常的简单，但是呢，经常会被忽略啊，如果你按照今天的这些改进的啊，这些方式去做的话呢，你后续的这个 sucle 的性能优化一定是非常有效果的， ok 啊，那么首先呢，我们来看第一段 soco 啊，就是斯莱克的希望 from restaurant 啊，大家现在可以暂停一下你的这个视频啊，然后我们弹幕一起交流一下他所存在的问题啊，其实很简单，就是咱 咱们使用了这个新号去查询对吧？啊，在我们公司啊，我不知道你们公司怎么样，我们公司的 dba 是明确规定的，数据库查询的时候不能够使用新号， 一定要写清楚你当前这个查询要返回哪些字段。那这个时候呢，可能有的同学就会啊疑问啊，不就是查询了所有字段吗？难道会有什么其他非常严重的问题吗？ 首先呢，就是你在使用 slog 的星的时候呢，数据库需要去解析更多的对象自断权限属性，那么在 soco 一句复杂应解析比较多的这种情况下呢，会对数据库造成非常沉重的这个负担，也就是他的这个计算的负担，对吧？ 那么另外一点呢，就是这个星号会带上所有的资段，如果说你的这个啊表当中某些资段，比如说是这个 blob 和 taxt 啊这种类型啊，那么你数据传输的这个 size 呢，就会啊非常的大啊。 另外呢，就是咱们现在这个微服务啊， db 和应用程序是分开的，对吧？所以说通过网络传输啊，这种数据库结果的时候呢，这个开销是非常非常大的 啊。另外一点呢，可能是一个面试题相关的，就是斯莱克的心，他失去了覆盖所引的这个可能性啊啊，比如说现在我们有一个表啊，他是 t， a， b， c， d， e， f 啊，其中呢，这个 a 是主见， b 呢是我们人为给他添加了一个缩影， 那这个时候呢，在磁盘上实际上是有两颗必加数的啊，也就是聚集所以和咱们这个辅助，所以啊分别保存的是 abcdef 和咱们的这个 ab 啊，这个地方可能有点云里雾里啊。我们说简单一点，全部的数据呢，我们给大家叫 data， 然后所以我们叫 index， 如果说查询条件中， where 条件可以通过 b 啊这个 b 列的缩影过滤掉一部分数据，那么这个时候呢，他的这个查询是优先走了 index， 那么如果说用户 只需要返回 a 和 b 啊这两列数据的话呢，那么直接通过 index 就可以查询并返回用户的这个数据，这个时候呢是非常非常快的啊。但是如果现在用户使用了这个斯莱克的星啊，他需要获取一些非 index 的数据，那么他的一个查询过程其实是这样的， 首先呢通过 index 过滤掉数据，然后再通过 data 啊去查询得到你其他的这些列的数据，对吧？那么这个时候呢，就无形当中增加了一次 b 加数的这个查询，相对于只查 ab 来讲会啊慢很多。 好的，那么这个斯莱克的心我们讲的有点多啊，接下来我们来讲一下这个小数据及驱动大数据级啊，其实就是讲一个啊，使用 in， 不要使用这个 exist 啊，怎么说呢，比如说现在我们有两张表，一个是 goods 啊，一个是这个 restaurants 啊，我们这个 restaurants 可能在数据库里面只有八千多条数据啊，但是这个 goods 它非常多， 有一百多万条啊，所以说他们两个的数量级是完全不一样的。当你去使用了这个 exist 的时候呢，他首先是会去查所有的这个故字，然后来过滤啊，这个 exist 里面的这些子句啊是否有包含，所以说他是先查大表再去过滤， 就是不满足小表里面的这些条件的这样的一些数据，对吧？啊？但是呢，我们如果使用了这个硬的话呢，他的一个查询正好是反过来的，首先呢他会去执行硬里面的这个查询语句，然后得到了一个条件啊，得到了一个数据集，比如说 id 的这个集合。然后呢我们再查询这个 裤子的时候啊，他会去走这样的一个比较小范围的查询啊，那么这个呢，就是小数据级驱动大数据级的一个策略啊，大家以后在写 sogo 的时候呢，都要尽量往这个方面去靠啊。另外这个地方我们还需要补充一点，就是啊，你需要考虑 考虑一下硬字段的这个内容会不会很多，如果很多的话呢，你需要去分批查询，然后避免这个返回数据量过大，造成程序的这个内存溢出啊。然后另外一点呢，就是我们公司实际上是不推崇像这样的一种写法，就是一条 so 口，但是里面操作了两张表。 我们通常的一个正确的做法是把这个 restaurant 啊这个里面的子句，首先在程序里面查出来，然后得到一个 id 的列表，然后呢再作为参数传给固子这张表的查询啊，这样就啊，一条 soco 只会去操作一张表啊， ok。 那么第三点呢，我们讲到的是批量插入代替这个循环插入啊，这个非常的简单，比如说现在我们有很多的 oder， 然后我们这样循环去操作，实际上性能是很低的， ok， 然后会多次去和数据库做一个交互，对吧？啊？我们其实正确的一个做法是使用这个买 is 他的一个 p 处理啊，就是 insert batch 啊，大概他最后执行的一个 circle 是这个样子， ok。 然后第四点呢，其实就是用 limit 限制返回的一个条数啊，因为我们公司有一个硬性的规定，就是你所有的这个 list 接口和 querry 接口呢，必须要做分页啊，因为有 size 才可以去避免内存溢出啊。 所以说大家在写色口的时候呢，也尽量能够去啊，做一下厘米茶，比如说你现在提供的是一个内部接口，他虽然说没有一个明确的 size， 但是你也可以去强制要求一下，比如说最多不能返回两千条啊，最多不能返回一千条等等，这样我觉得这个做了之后呢，会让你的这个程序有非常好的这个 稳定性啊，就不至于说啊，突然有一天某一个条件出发了一个非常大的查询，然后整个你的这个程序就挂了，这个之前我们也是有过线上故障复盘的一个经历的， ok， ok， 那么接下来呢，我们看一下第五点啊，就是同步数据的时候，我们去使用一个 update at 来检索出增量的数据啊，然后定时任务再去跑的时候呢，是可以以非常小的一个时间频率去跑这个增量数据的一个更新的，然后它也避免了全表的一个扫描啊，这个性能就非常的好，对吧？ 啊？实际应用的一个例子呢，就是我们公司会有一个 es 的锁引构建的定时任务，然后呢他再去跑这个 restaurant 的时候呢，只会去跑最近时间往前推两分钟的啊，这样的一些增量的数据啊， 我觉得这个是大家也可以去学习和借鉴一下。然后第六点呢，就是我们的一个分页优化啊，分页的查询优化，对吧？比如说我们这个地方啊，很简单啊，我们去查这个固字表，然后首先第一页是呃一，然后三十这样的一个 size， 对吧？但是呢它随着这个佩奇那么不断的增大分页往后啊，它的这个效率 率是非常低的， ok， 那么这个时候呢，我们其实可以去借助上一次查询的那个最大 id 啊，或者说上次查询的那个啊，欧德拜的那个阶段的一个最大值或者最小值来做一个啊条件的这个过滤啊，比如说这个地方我们就按最大的那个 id 吧，比如说前段这个时候呢，就可以把列表当中最后一条数据 返给我们，然后我们来作为一个条件的拼接，然后我们再去做一个分页的查询啊，这个时候就非常不错了， ok 啊，那么最后一点呢，就是缩小数据级的这个条件要放到前面啊，其实这个我觉得大家应该都能理解啊，就是比如说我们现在去查这个 restaurant 这张表， 然后现在呢，我们这个地方有一个 exdelyt 的等于零啊，就是所有没有删除的这个餐厅啊，我们把它查出来，但是呢其实这个地方并不是很好，如果说让我去改写的话，我会把 这个 wechat id 放到前面去啊，因为这个 wechat id， 比如说某一个大区，他可能只有三十多条数据，可能只有四十来条数据，对吧？然后我们再在这三十四十条数据当中呢，去过滤没有删除的，并且他的这个折扣率是大于二十的啊，那这个就啊比你 当前写的这个 east delete 等于零，然后再去过滤这个啊，它的这个数据过滤的这个数据级是要小很多的， ok， 那么所以说大家在啊写 cico 的时候呢，也尽量去往这方面来考虑一下啊，尽量能够让第一个查询条件就过滤掉非常多的数据， 然后减小你的这个数据集，然后不断你再往下走的时候呢，他的这个效率，是啊会越来越明显的。 ok， 好的，那以上呢就是本期视频的一个全部内容了，如果大家觉得这个视频做的还不错的话呢，请帮忙点赞、投币分享，一键三连支持我一下。那么如果你还没有关注我的这个频道啊，也请你点下关注，我的这个频道呢，是专注于程序员干货视频教程分享，关于程序员身心健康的这样一个频道。 ok， 我们下个视频再见吧。