mysql存在就更新,否则插入

2017-03-11 08:39:13

1- Mysql还有一种语法是 REPLACE INTO,存在就更新,否则插入
2- Mysql还有一种语法是 INSERT INTO ... ON DUPLICATE KEY UPDATE,存在唯一键键冲突就更新
3- 实际开发中大批量数据插入是很罕见的,至少1000条以下肯定不算大批量,所以如果你是想省事的话,通常你会验证一时偷懒节约了4小时所引起的麻烦够你折腾8小时这个预言。

通常大批量数据插入发生在数据从旧数据库中导入,但是这种导入通常只有一次,所以怎么认真对待都不为过,其它的比如从上传的csv文件中导入数据需要看具体的业务逻辑,比较常见的是使用try/catch进行插入,失败的数据显示出来,让用户确认覆盖,然后再update。


MySQL数据库中,遇到向某个表中插入数据的情况时,除了可以用insert into,也可以用replace into,但它们之间是有差别的

从字面上理解replace into含有更新替换的意思,

1.对于一个含有主键或者唯一索引的表来说,执行insert into操作时,如果表中已经存在记录,则不会执行,否则,会插入记录;

2.对于一个含有主键或者唯一索引的表来说,执行replace into操作时,如果表中已经存在记录,则会先将此记录删除,再插入replace into中的记录,否则,直接插入记录;

3.对于一个没有主键或者唯一索引的表来说,insert into和replace into的效果一样,都是向表中插入记录,但是replace into这种情况下的意义不大;

4.对于replace into的返回值而言,它返回的是操作的表中被影响的行数,其中包括删除的行数和插入的行数;




  • 2018-11-22 21:13:28

    webview之独立进程

    app内存占用大,被系统回收的概率就高,当每次把app切到后台再回到app时,可能每次app都会重启,最常见的是activity或fragment被回收了,导致fragment使用activity的数据时,出现NullPointerException。内存占用大,app越不稳定。运行性能差。webview加载页面后会占用更多的内存,从而导致app内存占用大,最终导致出现以上问题。

  • 2018-11-22 21:14:34

    为什么要采用WebView独立进程

    App中大量Web页面的使用容易导致App内存占用巨大,存在内存泄露,崩溃率高等问题,WebView独立进程的使用是解决Android WebView相关问题的一个合理的方案。

  • 2018-11-22 21:15:45

    Android WebView: 性能优化不得不说的事

    Mo说:大家通过前两篇文章想必都能顺利的 get 到 WebView 与 JavaScript 交互的技能了。现在 App 嵌入 H5 页面已经是稀松平常的事情了,开发者要面对 WebView 也越来越多的爆发出来,比如页面加载慢,内存泄露,不同 Android 系统版本采用了不同内核的兼容问题等等。 所以当我们使用了 WebView 这个组件的时候,性能优化的事情就不能不提上议程了。这篇文章我们就针对上述问题来总结下 Android WebView 性能优化的常见方法。 作者:MoTalksCn_林墨 链接:https://www.jianshu.com/p/95d4d73be3d1 來源:简书 简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

  • 2018-11-22 21:20:04

    WebView内存泄漏--解决方法小结

    Android混合开发时经常用到WebView加载html等页面,而WebView的内存泄漏就是最经常遇到的问题,尤其是当项目中需要用webview加载的页面比较多时。 即使当我退出页面时在我的BrowserActivity的onDestroy()方法中进行内存占用回收(如下图)但并没有效果:

  • 2018-11-23 09:19:27

    论索引的重要性

    我还有什么能说的呢,看来索引基本能解决一切慢sql。好开心。

  • 2018-11-26 17:03:59

    有些 where 条件会导致索引无效

    在查询中,WHERE 条件也是一个比较重要的因素,尽量少并且是合理的 where 条件是徆重要的,尽量在多个条件的时候,把会提取尽量少数据量的条件放在前 面,减少后一个 where 条件的查询时间。

  • 2018-11-26 17:05:47

    sql查询调优之where条件排序字段以及limit使用索引的奥秘

    看起来匪夷所思,其实搞清楚mysql查询的原理之后,其实很简单 我们来看这2条sql查询,都用到了where order by limit 当有limit存在时,查询的顺序就有可能发生变化,这时并不是从数据库中先通过where过滤再排序再limit 因为如果这样的话,从500万数据中通过where过滤就不会是5s了。