单元测试一般不允许有任何外部依赖（文件依赖/网络依赖/数据库依赖等），不会(or不能)在测试代码中去真正 连接数据库/调用api等。这些外部依赖在执行测试时需被模拟(mock/stub)。在测试时，使用模拟的对象来模拟真实依赖下的各种行为。如何运用mock/stub来模拟系统真实行为，算是单元测试道路上的一只拦路虎
Mock（模拟）和Stub（桩）是在测试过程中，模拟外部依赖行为的两种常用的技术手段。 通过Mock和Stub我们不仅可以让测试环境没有外部依赖，而且还可以模拟一些异常行为，如数据库服务不可用，没有文件的访问权限等等。
–搞定Go单元测试（一）——基础原理 之利用mock/stub 技术破除外部依赖
单元测试中只是针对单个函数的测试，关注其内部的逻辑，对于网络/数据库访问等，需要通过相应的手段进行 mock
xx公司 CI阶段在gitlab完成
xx的git flow： 所有feature基于master切出，完成开发后（uat环境，pre环境，原则上只能部署类似creative/test、creative/pre，creative-job/test，creative-job/pre这样的分支）。 用test（或pre分支）分支merge feature分支，部署test(或pre)进行测试。如果多人开发中有冲突，则解决。 最后用master来merge这个feature分支 (即 将feature分支合入master；feature一般如 creative/add_note_switch这样来命名)。
之后到gitlab页面，会有一合入master的选项。 代码提交后ep机器人会自动进行一系列检查(即所谓的pipeline)，如fmt，lint，unit-test覆盖率等check。如果必须通过的check都通过，同时还有两位(包含你自己)reviewers点赞，则会自动合入master。（有些必过check不过，也可以通过approvers强制合入，但一般这种属非正常流程。 角色的定义在项目OWNER文件中）
在此亲自实现这样一个功能：即代码提交后可实现自动lint，可进行单元测试覆盖率统计，进行构建和部署等
根据 局部性原理, MySQL Query Cache (QC) 会缓存select 查询( 默认开启),以减少下次查询需用的时间.
但如果对表进行 INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, DROP DATABASE 等操作, 则之前的缓存会失效且删除. 这样一定程度上也会影响数据库的性能, 故而对一些频繁变动的表, 开启缓存并不好; 另外在测试数据库性能时,也需要关闭QC,以避免其对测试结果的影响.
使用 rebase 所有人就好像都在同一条直线上开发一样，git log --graph 看着很舒服; 而使用 merge 的log看起来就很乱，有各种分叉，当要合入的分支会特别多时，更是如此.
2的0次方： 1
2的1次方： 2
2的2次方： 4
2的3次方： 8
2的4次方： 16
2的5次方： 32
2的6次方： 64
2的7次方： 128
2的8次方： 256
2的9次方： 512
2的10次方：1024
2的11次方：2048
2的12次方：4096
2的13次方：8192
2的14次方：16384
2的15次方：32768
2的16次方：65536
2的17次方：131072
2的18次方：262144
2的19次方：524288
2的20次方：1048576
2的21次方：2097152
2的22次方：4194304
2的23次方：8388608
2的24次方：16777216
2的25次方：33554432
2的26次方：67108864
2的27次方：134217728
2的28次方：268435456
2的29次方：536870912
2的30次方：1073741824
2的31次方：2147483648
2的32次方：4294967296
2的33次方：8589934592
2的34次方：17179869184
2的35次方：34359738368
2的36次方：68719476736
2的37次方：137438953472
2的38次方：274877906944
2的39次方：549755813888
2的40次方：1099511627776
2的41次方：2199023255552
2的42次方：4398046511104
2的43次方：8796093022208
2的44次方：17592186044416
2的45次方：35184372088832
2的46次方：70368744177664
2的47次方：140737488355328
2的48次方：281474976710656
2的49次方：562949953421312
2的50次方：1125899906842624
2的51次方：2251799813685248
2的52次方：4503599627370496
2的53次方：9007199254740992
2的54次方：18014398509481984
2的55次方：36028797018963968
2的56次方：72057594037927936
2的57次方：144115188075855872
2的58次方：288230376151711744
2的59次方：576460752303423488
2的60次方：1152921504606846976
2的61次方：2305843009213693952
2的62次方：4611686018427387904
2的63次方：9223372036854775808
2的64次方：18446744073709551616
Server抛给Client错误的 消息信息/错误值/SQLSTATE值 均列在源码share/messages_to_clients.txt文件中。“%d”和“%s”分别代表编号和字符串，显示时，它们将被消息值取代。
由于MySQL源码更新较频繁,以下内容可能缺失或有变更,虽然概率较小.
复旦大学2021年软件工程专业研究生考试,出了这道题(第4题),20分
