在 3.4 之前，之前如果一个 class 内部有循环引用，并重载了 del，的确会内存泄漏，celery4.1 就有这个 bug https://github.com/celery/celery/pull/4839

右键菜单里 follow tcp stream 就好了嘛, 论协议支持丰富性没有比 wireshark 强的.

手感特别软...很容易误触，我不习惯

escape 就是转义, 如果参数是 string, 具体到 pymysql 里就做了这个: https://github.com/PyMySQL/PyMySQL/blob/master/pymysql/converters.py#L72

我没看过 sqlalchemy 的实现, 但应该一样在 client 端转义的.

prepare 语句是可以防 sql 注入的: https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html

Protection against SQL injection attacks. The parameter values can contain unescaped SQL quote and delimiter characters.

这个和 set 转不转义没啥关系. 额, 这么想, 本来输入是一条 select, 通过注入拼接可能变成了一条 delete 语句, 但假如用的是 prepare, 提供给 prepare 的 sql 是你写的, 不会有用户输入, prepare 完它就是一条 select 语句, 后续你传入的 value 玩出花来 mysql 也只是把它当成一个文本参数, 不会再次执行 sql 的编译过程.

https://github.com/PyMySQL/PyMySQL/blob/master/pymysql/cursors.py#L161 mogrify 这个函数你跟下去看就知道了, 其实就是发送前把参数做了个本地 escape, 发出去的是一条拼好的 sql.

prepare 不是简单的字符串替换, 可以理解成在 prepare 阶段, sql 被解析成了 MySQL 内部类似 AST 那样的语法树结构,它知道你占位的地方是 input, 最后执行的时候, 不管输入的是什么, 都会被当成 value 去匹配, 而不是和前面的语句拼起来.

默认没有的, 一些工具通过覆盖 LD_PRELOAD 来劫持 execv 等 syscall, 间接得实现记录这个功能, 比如 https://github.com/a2o/snoopy

情愿看广告 +1

/tmp (狗头

写个 class 继承 dict,重载__setitem__,直接抛异常

小学语文课上老师就让我们这么干过，开篇是校园故事...后来变成了科幻小说

PTRACE_ATTACH

18 年 12 月买的 3m 9501,25 只 125

new 只是&T{}的一个语法糖

大同小异，我们 db migration 的工具是自己写的，但也没什么特别的，也是生成下 sql 然后执行。

实际上线的时候，如果有 schema change, 会分两次 deploy，第一次部署到单独的 server(日常主要是跑 cron,和一些手工脚本的，不承担用户流量)，在上面手工运行，用的 mysql(<8.0)原生的 online ddl,但这个也需要在流量低谷时候执行，io 开销很大。同时要求 schema change 做到兼容，第二次部署再把用到新 schema 结构的代码 rollout 到所有 server。整个过程没有 down time,但比较繁琐。

pt schema change 和 github 开源的那个工具原理也大同小异，好处是可以看到进度和控制速度，但和现有流程集成更麻烦点，没有在用。

完全自动化也不是不可能，但也要和线上流量做 trade off，对业务规模来说，得不偿失。业务要完全设计成 schemaless 也不太现实。

你写个程序在死循环里不停取时间，然后 strace 看它用了什么 syscall 就知道了

service topology: https://kubernetes.io/docs/concepts/services-networking/service-topology/

在 service 的定义里加一个 topologyKeys: ["kubernetes.io/hostname"], 就会优先同 node 的 endpoint

1.17 里还是 alpha