一次大表翻页实验
explain 的解释 https://www.cnblogs.com/butterfly100/archive/2018/01/15/8287569.html 假设慢查询是 100ms。 测试前准备一千万行数据 12345678910111213141516171819202122232425262728CREATE TABLE `tb_ins_pay_order` () ENGINE=InnoDB AUTO_INCREMENT=100 DEFAULT CHARSET=utf8mb4 COLLATE utf8mb4_unicode_ci COMMENT='';drop database test_db;create database test_db;drop table tb_ins_pay_order;truncate table tb_ins_pay_order;drop procedure if exists doWhile;DELIMITER // tb_ins_pay_orderCREATE PROCEDURE doWhile()BEGI...
六顶思考帽
六顶思考帽®是爱德华·德博诺博士开发的一种思维训练工具,它提供了“平行思维”的工具,全面思考问题的模型,避免将时间浪费在互相争执上。 人们参加会议都是抱着解决问题的共同目的而来的,然而发生争吵很多时候吵的并不是事实,而是情绪。人们总是还未真正理解对方的观点就陷入了和对方喋喋不休的争执之中。 所谓“六顶思考帽”是指蓝帽(指挥帽)、白帽(数据帽)、红帽(情感帽)、黄帽(乐观帽)、黑帽(谨慎帽)、绿帽(创新帽)。 六顶思考帽®是爱德华·德博诺博士开发的一种思维训练工具,它是目前全球最有影响力的创新思维训练课程。它提供了“平行思维”的工具,避免将时间浪费在互相争执上。强调的是“能够成为什么”,而非 “本身是什么”,是寻求一条向前发展的路,而不是争论谁对谁错。运用德博诺的六顶思考帽,将会使混乱的思考变得更清晰,使团体中无意义的争论变成集思广益的创造,使每个人变得富有创造性。它运用于会议管理,团队沟通,流程改进,产品研发/设计,制定决策,解决问题和领导力提升等领域。大部分世界500强企业学习使用过六顶思考帽后,都认为六帽帮助他们大大提高了工作效率,并且使会议时间减少了50%。自1984年被发...
MyISAM 和 InnoDB 的区别
参考:https://www.zhihu.com/question/20596402 区别: InnoDB 支持事务,MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一; InnoDB 支持外键,而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败; InnoDB 是聚集索引,MyISAM 是非聚集索引。聚簇索引的文件存放在主键索引的叶子节点上,因此 InnoDB 必须要有主键,通过主键索引效率很高。但是辅助索引需要两次查询,先查询到主键,然后再通过主键查询到数据。因此,主键不应该过大,因为主键太大,其他索引也都会很大。而 MyISAM 是非聚集索引,数据文件是分离的,索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 InnoDB 不保存表的具体行数,执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数,执行上述语句时只需要读出该变量即可,速度很快; InnoDB 最小的锁粒度是行锁,MyIS...
代码大全
第 1 章 欢迎进入软件构建的世界 第 2 章 用隐喻来更充分地理解软件开发 第 3 章 三思而后行:前期准备 第 4 章 关键的“构建决策” 第 5 章 软件构建中的设计 第 6 章 可以工作的类 第 7 章 高质量的子程序 第 8 章 防御式编程 第 9 章 伪代码编程过程 第 10 章 使用变量的一般事项 第 11 章 变量名的力量 第 12 章 基本数据类型 第 13 章 不常见的数据类型 第 14 章 组织直线型代码 第 15 章 使用条件语句 第 16 章 控制循环 第 17 章 不常见的控制结构 第 18 章 表驱动法 第 19 章 一般控制问题 第 20 章 软件质量概述 第 21 章 协同构建 第 22 章 开发者测试 第 23 章 调试 第 24 章 重构 第 25 章 代码调整策略 第 26 章 代码调整技术 第 27 章 程序规模对构建的影响 第 28 章 管理构建 第 29 章 集成 第 30 章 编程工具 第 31 章 布局与风格 第 32 章 自说明代码 第 33 章 个人性格 第 34 章 软件工艺的话题 第 35 章 何处有更多的信息
JUnit4/JUnit5 注解
junit4 junit5 特点 @BeforeClass @BeforeAll 在当前类的所有测试方法之前执行。注解在【静态方法】上。 @AfterClass @AfterAll 在当前类中的所有测试方法之后执行。注解在【静态方法】上。 @Before @BeforeEach 在每个测试方法之前执行。注解在【非静态方法】上。 @After @AfterEach 在每个测试方法之后执行。注解在【非静态方法】上。
彩色 UML 建模
理论基础与来源 彩色 UML 建模(也称为四色模型)是由 Peter Coad、Eric Lefebvre 和 Jeff De Luca 在经典著作《Java Modeling in Color with UML》中提出的领域建模方法。该方法通过四种颜色区分不同类型的域对象,帮助开发人员更好地理解和设计业务领域模型。 四色模型的核心思想是将领域对象分为四种架构型(Archetype),每种架构型用不同的颜色表示: 粉色(Moment-Interval):表示业务过程中发生的某个时刻或时段 黄色(Role):表示参与方在特定时刻时段中扮演的角色 绿色(Party-Place-Thing):表示参与方、地点和事物 蓝色(Description):表示描述性信息,通常是可重用的数据 四色模型与 DDD 的关系 四色模型与领域驱动设计(Domain-Driven Design,DDD)有很强的关联性: 关注领域本质:两者都强调深入理解业务领域,建立符合业务语义的模型 限界上下文:四色模型的彩色分类可以帮助识别和定义限界上下文 聚合根:粉色 MI 通常对应聚合根,负责维护业务不变性 ...
IPv6 问题
背景 IPv4 地址枯竭 5G、IOT、SDN/NFV、云计算、边缘计算等新兴技术兴起,需要地址的终端设备变多。 NAT 技术无法支持新兴技术。 各大互联网公(国外的Google、AWS、Apple,国内的阿里、滴滴等公司)司要定期推动本公司业务的 ipv6 技术改造,网信办会定期检查,不达标的公司要问责。 改造要点 因为IP地址长度从32位变为128,文本格式从十进制数字变为十六进制(见附录1),为支持两种IP地址,包括但不限于以下改造要点: 客户端(手机APP和浏览器)缓存用户IP 后端服务根据IP做判断的业务逻辑, 比如set化、小流量。 用户IP归属地查询。 用户IP白名单、黑名单。 风控使用到IP段的策略。 存储用户IP到DB或者缓存 IPv4是32位,可以转成int或者long来存储。 IPv6是128位,不能使用long或者bigint来计算存储。 在服务接口之间传递用户IP 内网之间传递,典型的是支付、风控等。 外网之间传递,如第三方微信支付等。 日志处理 后端日志落地为IPv6后,是否有通过日志内容处理的业务逻辑。 依赖ngin...
亚马逊工作方法
一、亚马逊14条领导力原则 我们的领导力准则不仅仅是非常鼓舞人心的墙帷。这些准则十分有效,就像我们努力工作所取得的成果一样。无论是在讨论新项目的创意、决定应对客户问题的最佳解决方案,还是对求职者进行面试,亚马逊人每天都在使用这些准则。这是令亚马逊独具特色的一个重要因素。 顾客至尚(Customer Obsession)领导者从客户入手,再反向推动工作。他们努力地工作以赢得并维系客户对他们的信任。虽然领导者会关注竞争对手,但是他们更关注客户。 主人翁精神(Ownership)领导者是主人翁。他们会从长远考虑,不会为了短期业绩而牺牲长期价值。他们不仅仅代表自己的团队,而且代表整个公司行事。他们绝不会说“那不是我的工作”。 创新简化(Invent and Simplify)领导者期望并要求自己的团队进行创新和发明,并始终寻求使工作简化的方法。他们了解外界动态,从各处寻找新的创意,并且不局限于“非我发明”的观念。 当我们开展新事物时,我们要接受被长期误解的可能。 决策正确(Are Right, A Lot)领导者在大多数情况下都能做出正确的决定。他们拥有卓越的业务判断能力...
微服务相关文献
《提升团队的微服务落地能力》
滚动重启、金丝雀发布、AB testing 和蓝绿部署
本文讨论发布周期(release cycles)里 deployment strategy 的问题,抛开大规模部署的 big bang deployment。 滚动重启、金丝雀发布、AB testing 在 martin fowler 的博客里,金丝雀发布和滚动重启和 AB testing 并没有本质区别,都是 phased approach或者 incremental approach,是 ParallelChange 思想的实践。 当我们拥有一个新版本时: 滚动重启(rolling restart) rolling restart 会让新旧版本在环境里长时间共存,逐一使节点部署新版本,这样易于发现问题和回滚。 金丝雀发布(canary release) 而金丝雀发布同样允许新旧版本长时间共存,在逐一部署新节点的前提下,逐步利用 LB 之类的基础设施来切分用户,其策略还可以细分为: 先不给新版本,在无流量的情况下在生产环境验证 - 很多大厂的实现都忽略了这点。 尽量让内部用户先使用 - FB 之类的大厂的员工都非常多,使用一个特性开关(名字很多,比如 feature bits,...















