MySQL "replace into" 的坑
MySQL 对 SQL 有很多扩展,有些用起来很方便,但有一些被误用之后会有性能问题,还会有一些意料之外的副作用,比如 REPLACE INTO。
MySQL 对 SQL 有很多扩展,有些用起来很方便,但有一些被误用之后会有性能问题,还会有一些意料之外的副作用,比如 REPLACE INTO。
前几天又有同事掉进了给 SQL 的 IN 条件传参的坑,就像 SELECT col1, col2 FROM table1 WHERE id IN (1, 2, 3) 这类 SQL,如果是一个可变的列表作为 IN 的参数,那这个参数应该怎么传呢?
在 Linux 下要确认一个进程的发起者身份,比如用户 tom 登录系统,sudo su - 到 root,然后执行了脚本 hey.sh,要想在 hey.sh 中追溯到发起进程的是 tom 这个用户,并不是很容易做到准确无误,花了点时间,找到了一个相对靠谱的方式。
之前一直以为 hosts 不支持把一个名字解析到多个 IP,因此凡是有解析到多个 IP 需求的场景,全部都使用了 DNS,偶然看 host.conf 的 man page,发现并不是这样,有些场景下仍然是可以使用 hosts 的。