Skip to main content

Home/ Larvata/ Group items tagged 设计

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

深度解读 - TDD（测试驱动开发） - 简书 - 0 views

www.jianshu.com/62f16cd4fef3

development programming test

shared by 張 旭 on 31 Mar 17 - No Cached
  • TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
  • TDD 并不能直接提高设计能力，它只是给你更多机会和保障去改善设计。
  • 写测试，只关注需求，程序的输入输出，不关心中间过程
  • ...21 more annotations...
  • 写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可
  • 一次只关注一个点，思维负担更小
  • 提前澄清需求细节
  • 写一个失败的测试，它是对一个小需求的描述，只需要关心输入输出，这个时候根本不用关心如何实现
  • 专注在用最快的方式实现当前这个小需求，不用关心其他需求，也不要管代码的质量多么惨不忍睹
  • 既不用思考需求，也没有实现的压力，只需要找出代码中的坏味道，并用一个手法消除它，让代码变成整洁的代码
  • TDD 之前要拆分任务，把一个大需求拆成多个小需求。
  • 符合 Given-When-Then 格式
  • 包含断言
  • 可以重复执行
  • 单元测试基础设施
  • 只在没有信心的地方写测试代码
  • 有注释的地方都可以抽取方法，用方法名来代替注释
  • 选一个最简单的用例，直接开写，用最简单的代码通过测试。逐渐增加测试，让代码变复杂，用重构来驱动出设计。
  • 有了重构这个工具后，做设计的压力小了很多，因为有测试代码保护，我们可以随时重构实现了
  • 在纸上迭代总比改代码要快
  • 任务分解和列 Example
  • 步子迈太大，容易扯着蛋。
  • 做探索性的技术研究（Spike），不需要长期维护，而且测试基础设施搭建成本很高，那还是手工测试吧
  • TDD 是开发人员自己的事
  • 布置完一个任务，让新人先画图，就可以在他开始写代码前对他的设计提反馈。
  • 張 旭 on 31 Mar 17
     
    "TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。"
kickdesk

卡片式设计，并不能支撑所有的设计需求 | 人人都是产品经理 - 0 views

www.woshipm.com/503654.html

设计 UX UI

shared by kickdesk on 12 Dec 16 - No Cached
  • kickdesk on 12 Dec 16
     
    這是一份可以提供PM跟客戶講佈局的參考文章，中間有注意力停留的數據
張 旭

从达标到卓越 -- API 设计之道 | Taobao FED | 淘宝前端团队 - 0 views

taobaofed.org/...index.html

api system development programming taobao

shared by 張 旭 on 21 Feb 17 - No Cached
  • 高级语言和自然语言（英语）其实相差无几，因此正确地使用（英语的）词法和语法是程序员最基本的素养。
  • 只要能够足够接近人类的日常语言和思维，并且不需要引发额外的大脑思考，那就是易用
  • 词法和语法
  • ...53 more annotations...
  • 语义
  • 版本控制
  • 正确地拼写一个单词是底线
  • 认真地注意 IDE 的 typo 提示（单词拼写错误提示）
  • state 是整个 Component 状态机中的某一个特定状态，既然描述为了状态机，那么状态和状态之间是互相切换的关系。所以对于初始状态，用 initial 来修饰。
  • props 是指 Element 的属性，要么是不存在某个属性值后来为它赋值，要么是存在属性的默认值后来将其覆盖。所以这种行为，default 是合理的修饰词。
  • 成对出现的词应该是：show & hide、open & close。
  • 成对出现的正反义词不可混用
  • 在复数的风格上保持一致，要么所有都是 -s，要么所有都是 -list。
  • 涉及到诸如字典（Dictionary）、表（Map）的时候，不要使用复数！
  • 「map」本身已经包含了这层意思，不需要再用复数去修饰它
  • 最好遵从惯例，使用名词组合 success 和 failure
  • 方法命名用动词
  • 属性命名用名词
  • 布尔值类型用形容词
  • 首字母缩写词的所有字母均大写。（如果某个语言环境有明确的业界惯例，则遵循惯例。）
  • 如果什么都没定，也没业界惯例，那么把单词写全了总是不会错的。
  • React 采用了 componentDidMount 这种过去时风格，而没有使用 componentMounted，从而跟 componentWillMount 形成对照组，方便记忆。
  • 尽量避免使用被动语态。因为被动语态看起来会比较绕，不够直观，因此我们要将被动语态的 API 转换为主动语态。
  • 无论是友好的参数设置，还是让人甜蜜蜜的语法糖，都体现了程序员的人文关怀。
  • 在文件（file）层面同样如此，一个文件只编写一个类，保证文件的职责单一（当然这对很多语言来说是天然的规则）。
  • 将混杂在一个大坨函数中的两件独立事情拆分出去，保证函数（function）级别的职责单一。
  • 现实中的 OOP 编程场景难免触及副作用。
  • 函数本身的运行稳定可预期
  • 函数的运行不对外部环境造成意料外的污染
  • SPM 是阿里通用的埋点统计方案
  • 对外部造成污染一般是两种途径：一是在函数体内部直接修改外部作用域的变量，甚至全局变量；二是通过修改实参间接影响到外部环境，如果实参是引用类型的数据结构。
  • 控制读写权限
  • 优化参数顺序。相关性越高的参数越要前置
  • 可省略的参数后置，以及 为可省略的参数设定缺省值
  • 将可省参数后置同样是最佳实践。
  • 重载（overload）
  • 如果入口参数无法进行有效区分，不要选择重载
  • 根本不明白某个 Boolean 标记位是用来干嘛的，这大大降低了用户的开发体验，以及代码可读性。
    • 張 旭
      張 旭 on 21 Feb 17
       
      我在 ADATA 的 message saver 犯了一樣的錯誤。
  • 同时支持单个和批量的处理，可以降低用户的认知负担。
  • 让 setter 型 API 始终返回 this。这是 jQuery 为我们带来的经典启示 —— 通过返回 this，来产生一种「链式调用（chaining）」的风格
  • 对异步操作都返回一个 Promise
  • 对于一些创造出来的、业务特色的词汇，如果不能用英语简明地翻译，就直接用拼音
  • 一致性可以最大程度降低信息熵
  • 打 log 要么都用中文，要么都用英文。
  • 所有的 setter 操作必须返回 this
  • 「大版本号」即「语义化版本命名」<major>.<minor>.<patch> 中的第一位 <major> 位
  • 接口的扩展方式有很多，比如：继承（extend）、组合（mixin）、装饰（decorate）
  • 在逻辑上确实存在派生关系，并且需要沿用基类行为同时自定义行为的，采用重量级的继承
  • 仅仅是扩充一些行为功能，但是逻辑上压根不存在父子关系的，使用组合
  • 装饰手法更多应用于给定一个接口，将其包装成多种适用于不同场景新接口的情况
  • $.fn.customMethod = function() {};
  • 合理的做法是新增一个 subType 字段
  • 抽象级别一般来说越高越好，将 API 设计成业务无关的，更通用，而且方便扩展
  • 利用多态性（Polymorphism）构建 Consistent APIs。
  • 作为 API 的开发者，一定要提供足够场景适用的 API，来引导我们的用户，不要让他们做出一些出人意料的「妙用」之举
  • 写代码，就像写作，而设计 API 好比列提纲。
  • Think about future, design with flexibility, but only implement for production.
crazylion lee

Hybrid APP架构设计思路 · Issue #12 · chemdemo/chemdemo.github.io - 0 views

github.com/...12

hybrid app

shared by crazylion lee on 10 Feb 16 - No Cached
  • crazylion lee on 10 Feb 16
     
    "关于Hybrid模式开发app的好处，网络上已有很多文章阐述了，这里不展开。 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考。"
張 旭

我做系统架构的一些原则 | 酷 壳 - CoolShell - 0 views

coolshell.cn/21672.html

system architecture

shared by 張 旭 on 03 Jan 22 - No Cached
  • 如果不说收益，只是为了技术而技术，而没有任何意义。
  • 有计划和无计划的停机做相应的解决方案
  • 经常不断的 human error
  • ...35 more annotations...
  • 运维又会分成基础运维和应用运维，开发则会分成基础核心开发和业务开发。
  • 基础运维和开发的同学更多的只是关注资源的利用率和性能，而应用运维和业务开发则更多关注的是应用和服务上的东西。
  • 有一些系统已经说不清楚是基础层的还是应用层的了，比如像服务治理上的东西，里面即有底层基础技术，也需要业务的同学来配合，包括 k8s 也样，里面即有底层的如网络这样的技术，也有需要业务配合的 readniess和 liveness 这样的健康检查，以及业务应用需要 configMap 等等 ……
  • 试想一下城市交通的优化，当城市规模到一定程度的时候，整体的性能你是无法通过优化几条路或是几条街区来完成的，你需要对整个城市做整体的功能体的规划才可能达到整体效率的提升
  • 当系统越来越复杂的时候，用户把他们的  PHP，Python, .NET，或 Node.js 的架构完全都迁移到 Java + Go 的架构上来的案例不断的发生。
  • 更为工业化的技术
  • 使用更为成熟更为工业化的技术栈，而不是自己熟悉的技术栈
  • 不要自己发明轮子，更不要魔改
  • 完全没有必要。不重新发明轮子，不魔改，不是因为自己技术不能，而是因为，这个世界早已不是自己干所有事的年代了
  • 好些公司的架构都被技术负责人个人的喜好、擅长和个人经验给绑架了，完全不是从一个客观的角度来进行技术选型
  • 全中国所有的电商平台，几百家银行，三大电信运营商，所有的保险公司，劵商的系统，医院里的系统，电子政府系统，等等，基本都是用 Java 开发的，包括 AWS 的主流语言也是 Java
  • NoSQL 的数据库在 Join 上都表现的太差
  • 为了不做 Join 就开始冗余数据，然而自己又维护不好冗余数据后带来的数据一致性的问题，导致数据上的各种错乱丢失。
  • 永远使用完备支持 ACID 的关系型数据库
  • 性能上的事，总是有解的，手段也是最多的，这个比起架构的完备性和扩展性来说真的不必太过担心。
  • 很多公司的系统既没有服从业界标准，也没有形成自己公司的标准，感觉就像一群乌合之众一样。
  • 最典型的例子就是 HTTP 调用的状态返回码。业内给你的标准是 200表示成功，3xx 跳转，4xx 表示调用端出错，5xx 表示服务端出错，我实在是不明白为什么无论成功和失败大家都喜欢返回 200，然后在 body 里指出是否error
  • Restful API 的规范。我觉得是非常重要的，这里给两个我觉得写得最好的参考：Paypal 和 Microsoft 。
  • 监控系统宁可自己死了也不能干扰实际应用。
  • 一个公司至少一年要有一次软件版本升级的review，然后形成软件版本的统一和一致
  • 架构和软件不是写好就完的，是需要不断修改不断维护的，80%的软件成本都是在维护上。
  • 通过服务发现或服务网关来降低服务依赖所带来的运维复杂度
  • 一定要使用各种软件设计的原则。比如：像SOLID这样的原则（参看《一些软件设计的原则》），IoC/DIP，SOA 或 Spring Cloud 等 架构的最佳实践（参看《SteveY对Amazon和Google平台的吐槽》中的 Service Interface 的那几条军规），分布式系统架构的相关实践（参看：《分布式系统的事务处理》，或微软件的 《Cloud Design Patterns》）……等等
  • 没有自动化测试，没有好的软件文档，没有质量好的代码，没有标准和规范
  • 以前欠下的技术债，都得要还，没打好的地基要重新打，没建配套设施都要建。这些基础设施如果不按照正确科学的方式建立的话，你是不可能有一个好的的系统
  • 与其花大力气迁就技术债务，不如直接还技术债
  • 建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不要让技术债侵入“新城区”。
  • 如果有一天你在做技术决定的时候，开始凭自己以往的经验，那么你就已经不可能再成长了。
  • 做任何决定之前，最好花上一点时间，上网查一下相关的资料，技术博客，文章，论文等 ，同时，也看看各个公司，或是各个开源软件他们是怎么做的？然后，比较多种方案的 Pros/Cons，最终形成自己的决定
  • 对于 X-Y 问题，也就是说，用户为了解决 X问题，他觉得用 Y 可以解，于是问我 Y 怎么搞，结果搞到最后，发现原来要解决的 X 问题，这个时候最好的解决方案不是 Y，而是 Z。
  • 我很喜欢追问为什么 ，这种追问，会让客户也跟着来一起重新思考。
  • 激进并不是瞎搞，也不是见新技术就上，而是积极拥抱会改变未来的新技术
  • 不是不喜欢的就不学了，我对区块链和 Rust 我一样学习，我也知道这些技术的优势，但我不会大规模使用它们。
  • 进步永远来自于探索，探索是要付出代价的，但是收益更大。
  • 不敢冒险才是最大的冒险，不敢犯错才是最大的错误，害怕失去会让你失去的更多
張 旭

单表60亿记录等大数据场景的MySQL优化和运维之道 - 快课网 - 0 views

www.cricode.com/3981.html

mysql system performance HA database

shared by 張 旭 on 18 Nov 15 - No Cached
  • 存储引擎使用InnoDB
  • 变长字符串尽量使用varchar varbinary
  • 不在数据库中存储图片、文件等
  • ...34 more annotations...
  • 库名、表名、字段名、索引名使用小写字母，以下划线分割 ，需要见名知意
  • 所有字段均定义为NOT NULL ，除非你真的想存Null
  • 使用TIMESTAMP存储时间
  • 使用DECIMAL存储精确浮点数，用float有的时候会有问题
  • 单个索引字段数不超过5，单表索引数量不超过5，索引设计遵循B+ Tree索引最左前缀匹配原则
  • 建立的索引能覆盖80%主要的查询，不求全，解决问题的主要矛盾
  • 避免冗余索引
  • 索引这个东西是一把双刃剑，在加速读的同时也引入了很多额外的写入和锁，降低写入能力
  • 字段定义为varchar，但传入的值是个int，就会导致全表扫描，要求程序端要做好类型检查
  • 避免使用大表的JOIN，MySQL优化器对join优化策略过于简单
  • UPDATE、DELETE语句不使用LIMIT ，容易造成主从不一致
  • 高危操作检查，Drop前做好数据备份
  • 日志分析，主要是指的MySQL慢日志和错误日志
  • Percona公司根据Facebook OSC思路，用perl重写了一版，就是我们现在用得很多的pt-online-schema-change，软件本身非常成熟，支持目前主流版本
  • 原生主从同步肯定存在着性能和安全性问题
  • Sharding is very complex, so itʼs best not to shard until itʼs obvious that you will actually need to!
  • 有中间层控制拆分逻辑最好，否则拆分过细管理成本会很高
  • 全量binlog备份
  • xtrabackup热备
  • 采用分布式文件系统存储备份
  • 基于库级别的复制，所以如果你只有一个库，使用这个意义不大
  • 半同步复制，从5.5开始支持
  • 半同步通过从库返回ACK这种方式确认从库收到数据
  • Secondsbehindmaster来判断延时不可靠，在网络抖动或者一些特殊参数配置情况下，会造成这个值是0但其实延时很大了。通过heartbeat表插入时间戳这种机制判断延时是更靠谱的
  • Binlog格式，建议都采用row格式，数据一致性更好
  • 成熟开源事务存储引擎，支持ACID，支持事务四个隔离级别，更好的数据安全性，高性能高并发，MVCC，细粒度锁，支持O_DIRECT
  • 数据安全性至关重要，InnoDB完胜
  • 主流使用TokuDB主要是看中了它的高压缩比
  • TokuDB在测试过程中写入稳定性是非常好的
  • 单表容量在InnoDB下1TB+，使用Tokudb的lzma压缩到80GB
  • 独立写程序好一些，与程序解耦方便后期维护
  • 追踪字段值变化可以通过分析row格式binlog好一些
  • 解决了单表过大恢复时间问题，也支持online DDL
  • 物理备份采用xtrabackup热备方案比较好
張 旭

数据库水平分片心得 · ScienJus's Blog - 0 views

www.scienjus.com/database-sharding-review

database mysql system

shared by 張 旭 on 29 Oct 18 - No Cached
  • 水平分片（也叫水平分库）指的是将整体存储在单个数据库中的数据，通过某种策略分摊到多个表结构与其相同的数据库中，这样每个数据库中的数据量就会相对减少很多，并且可以部署在不同物理服务器上，理论上能够实现数据库的无限横向拓展。
  • 当遇到第一次数据库性能问题时，最先想到的方案应该是读写分离，将所有写操作都放在主数据库上，所有读操作都放在从数据库上
  • 配置一主多从
  • ...16 more annotations...
  • 主从关系（Master-Slave），此时所有操作还是由主数据库完成，主数据库再同步到从数据库上，而从数据库只需要在主数据库挂掉之后代替其工作。
  • 一般来说读写分离加上缓存已经可以应付绝大多数情况了，并且几乎不需要对业务层面进行修改。
  • 对数据库进行垂直分库，将业务彼此无关的表放在单独的数据库中，分库后不同库中的表无法进行联合查询等操作，但是可以平摊压力，并且独立做读写分离。
  • 对数据库进行水平分表，建立多个结构相同的表分摊数据，使得每个表的数据量减少从而提升速度。
  • 分表却只能在单台机器的单个数据库上，如果是服务器本身的性能达到瓶颈，则分表不会有明显作用。
  • 分表后各个子表还是可以通过 union 等命令联合查询，分库后则不行
  • 基于 id 的区间分片，例如：将 id 为 1-2w 的数据存放在 A 数据库，2w-4w 的数据存放在 B 数据库。
  • 基于 id 的 hash 分片，例如：将 id%2=0 的数据存放在 A 数据库，id%2=1 的数据放在 B 数据库。
  • 基于时间的区间分片，大部分软件都会有一个特征：越新的数据被操作的几率越大，老数据几乎不会被操作。所以通过数据的插入时间进行分库（也称为冷热分离）
  • 基于检索表分片，通过额外建立一张检索表保存 id 与所在数据库节点的对应关系，优点是逻辑简单，自由且不会有迁移问题，缺点是每次查询都需要额外查询检索表，所以一般会选择将检索表缓存到内存中。
  • 基于地理位置分片
  • 分库策略
  • 在数据库表设计时，为了保证 id 唯一，大部分人都会将主键设为自增的 int 类型。但是由于 auto\_increment 是和表所绑定的，所以在分库后每个表的自增 id 也是独立的。这样就肯定会发生主键冲突
  • 但是很多人都希望主键即使不是连续自增，也是一个有序的整数，这样在排序等情况下会有用。这时候就需要自己实现一个 id 生成算法了，一般都会使用 unix 时间戳保持有序，混入 Mac 地址等保证唯一。
  • 在分库情况下，需要将大部分联合查询都替换为至少两次查询，先从关联的表中查询出符合条件的 id，在根据 id 去对应的数据库里查询主体信息。
  • 数据库水平分片作为数据库性能瓶颈的最终解决方案，确实可以有效的解决这个问题。但是它将业务逻辑变得非常复杂（主要是关联表冗余和字段冗余，以及这些数据的更新），并且有分布式事务这个难题。所以不到必要时刻，尽量不要轻易尝试数据库分片。
張 旭

从《凤凰项目》谈一谈"业务IT一体化" - 知乎 - 0 views

zhuanlan.zhihu.com/27662792

devops system

shared by 張 旭 on 29 Dec 18 - No Cached
  • IT能多大程度上参与到业务系统中去帮助到业务部门，甚至影响到业务部门，你的价值就有多大。这项工作列为紧急并且重要
  • “IT内部的项目”，有一些IT部门很热衷做这方面的项目，在我看来部分的原因是因为做这些东西相对来说是IT比较好玩或者擅长的。
  • 重要但不紧急的工作，例如认真地研究和建立devops的基础环境。
  • ...11 more annotations...
  • 但变更虽然不可避免，我个人觉得应该尽可能减少（至少做到可预测），并且将变更流程自动化。
  • 最容易被人忽视的是“计划外工作”，它偷走了我们的时间。这就等于我们经常在讲的那些紧急但不重要，或者那些不紧急也不重要的事情。
  • 约束管理（ Theory Of Constrain ）理论
  • 他太厉害，所以不屑于写文档；他太重要，所以可以随心所欲地改东西而不走流程；他太忙，所以很多事情都要排队等他的时间来做。
  • 需要布伦特这样的人才，只是说布伦特成为了团队的约束点，怎么利用好他成为工作成败的关键（建立一些好的机制，确保他们能够更好地工作，而不是在一些低价值的内容上），而怎么帮助他提高到一个新的水平（或者培养更多的布伦特）才是长治久安的方法。
  • “业务IT一体化”与传统的模式有一个根本的区别，就是大量地使用了自动化的技术，减少中间环节。
  • IT部门内部开发、测试、运维、安全等环节的信任
  • 第一步，从产品构想、设计、开发、测试、运维到客户，这个正向的工作流，一定要理顺
  • 第二步，从客户往回推，如何建立一个健康和高效的反馈流。这里我总结为快速试错和迭代
  • 第三步，我觉得是讲到点子上了—— 业务IT一体化当然是好啊，但流程再合理，工具再强大，领导再重视，如果没有一个所有员工都认同的企业文化来做支撑，都将流于形式。没有信任来谈创新，终究是扯淡。
  • 各部门只关注自己的小目标，以自己干了多少事为荣，而不管这些事到底对于整个公司的目标实现意味着什么。
張 旭

DevOps - 0 views

mp.weixin.qq.com/...oELHwosd26dS4_qh5HEZRw

devops system

shared by 張 旭 on 27 Feb 19 - No Cached
  • 对于运维来说，知识的传承非常重要，非常有必要建立运维的知识库。一方面 有利于对事件的复盘回顾，另一方面也有助于日后参加运维的人员尽快熟悉与掌握系统的运维技能
  • 云平台主要从以下3个方面对DevOps提供支撑（括号内为承载此能力的软件工具）： 1. 基于IaaS的自服务与环境编排能力（VMWare） 2. 基于PaaS的弹性伸缩能力（K8s） 3. 基于SaaS的软件服务能力
  • 考虑自建私有云，至少是混合云。
  • ...11 more annotations...
  • 内网建立所谓的私库，作为代理与外网的公共库同步。
  • 很难做到真正意义上的DevOps to Production
  • 可视化是为了实时展现持续交付流水线执行情况与单元测试的执行报告
  • 通过持续交付流水线串联自动化测试，在测试环境部署成功后触发自动化测试。
  • 测试阶段也需要测试报告的可视化与结果通知
  • 企业的持续交付流水线往往都打不通到生产环境
  • Service Desk不是某一款软件的名字，而是ITIL（信息技术基础架构库，可认为是ITSM的落地实现）里面承载变更管理与事件管理的工具统称。
  • 构建底层的云平台，是整个DevOps基础架构的基石
  • 架构不是一成不变的，而是应该随着实际需求变化而持续演化，能力也要跟着持续提升。
  • 并行测试的执行环境通过PaaS平台按需自动生成，测试执行完毕后自动销毁。
  • 即使是雷同的项目，在对编译构建上的一些细枝末节的差别也很可能导致它们的持续交付流水线设计非常不一样。
  • 張 旭 on 27 Feb 19
     
    "对于运维来说，知识的传承非常重要，非常有必要建立运维的知识库。一方面 有利于对事件的复盘回顾，另一方面也有助于日后参加运维的人员尽快熟悉与掌握系统的运维技能。"
張 旭

我必须得告诉大家的MySQL优化原理 - 简书 - 0 views

www.jianshu.com/d7665192aaaf

mysql performance system

shared by 張 旭 on 19 Aug 17 - No Cached
  • 很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已
  • MySQL客户端/服务端通信协议是“半双工”的：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时发生。
  • 当查询语句很长的时候，需要设置max_allowed_packet参数。
  • ...70 more annotations...
  • 如果查询实在是太大，服务端会拒绝接收更多数据并抛出异常
  • 服务器响应给用户的数据通常会很多，由多个数据包组成
  • 减小通信间数据包的大小和数量是一个非常好的习惯
  • 查询中尽量避免使用SELECT *以及加上LIMIT限制
  • 在解析一个查询语句前，如果查询缓存是打开的，那么MySQL会检查这个查询语句是否命中查询缓存中的数据。
  • 两个查询在任何字符上的不同（例如：空格、注释），都会导致缓存不会命中。
  • MySQL将缓存存放在一个引用表
  • 如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表，其查询结果 都不会被缓存。
  • MySQL的查询缓存系统会跟踪查询中涉及的每个表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。
  • 在任何的写操作时，MySQL必须将对应表的所有缓存都设置为失效。
  • 查询缓存对系统的额外消耗也不仅仅在写操作，读操作也不例外
  • 任何的查询语句在开始之前都必须经过检查，即使这条SQL语句永远不会命中缓存
  • 如果查询结果可以被缓存，那么执行完成后，会将结果存入缓存，也会带来额外的系统消耗
  • 并不是什么情况下查询缓存都会提高系统性能，缓存和失效都会带来额外消耗
  • 用多个小表代替一个大表
  • 批量插入代替循环单条插入
  • 合理控制缓存空间大小
  • 可以通过SQL_CACHE和SQL_NO_CACHE来控制某个查询语句是否需要进行缓存
  • 不要轻易打开查询缓存，特别是写密集型应用
  • 将query_cache_type设置为DEMAND，这时只有加入SQL_CACHE的查询才会走缓存，其他查询则不会，这样可以非常自由地控制哪些查询需要被缓存。
  • 预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。
  • 一条查询可以有很多种执行方式，最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。
  • 查询当前会话的last_query_cost的值来得到其计算当前查询的成本。
  • 尝试预测一个查询使用某种执行计划时的成本
  • 有非常多的原因会导致MySQL选择错误的执行计划
  • MySQL值选择它认为成本小的，但成本小并不意味着执行时间短
  • 提前终止查询（比如：使用Limit时，查找到满足数量的结果集后会立即终止查询）
  • 找某列的最小值，如果该列有索引，只需要查找B+Tree索引最左端，反之则可以找到最大值
  • 在完成解析和优化阶段以后，MySQL会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。
  • 查询过程中的每一张表由一个handler实例表示。
  • MySQL在查询优化阶段就为每一张表创建了一个handler实例，优化器可以根据这些实例的接口来获取表的相关信息
  • 即使查询不到数据，MySQL仍然会返回这个查询的相关信息，比如改查询影响到的行数以及执行时间等等。
  • 结果集返回客户端是一个增量且逐步返回的过程
  • 整型就比字符操作代价低，因而会使用整型来存储ip地址，使用DATETIME来存储时间，而不是使用字符串。
  • 如果计划在列上创建索引，就应该将该列设置为NOT NULL
  • UNSIGNED表示不允许负值，大致可以使正数的上限提高一倍。
  • 没有太大的必要使用DECIMAL数据类型。即使是在需要存储财务数据时，仍然可以使用BIGINT
  • 大表ALTER TABLE非常耗时
  • MySQL执行大部分修改表结果操作的方法是用新的结构创建一个张空表，从旧表中查出所有的数据插入新表，然后再删除旧表
  • 索引是提高MySQL查询性能的一个重要途径，但过多的索引可能会导致过高的磁盘使用率以及过高的内存占用，从而影响应用程序的整体性能。
  • 索引是指B-Tree索引，它是目前关系型数据库中查找数据最为常用和有效的索引，大多数存储引擎都支持这种索引
  • B+Tree中的B是指balance，意为平衡。
  • 平衡二叉树首先需要符合二叉查找树的定义，其次必须满足任何节点的两个子树的高度差不能大于1。
  • 索引往往以索引文件的形式存储的磁盘上
  • 如何减少查找过程中的I/O存取次数？
  • 减少树的深度，将二叉树变为m叉树（多路搜索树），而B+Tree就是一种多路搜索树。
  • 页是计算机管理存储器的逻辑块，硬件及OS往往将主存和磁盘存储区分割为连续的大小相等的块
  • B+Tree为了保持平衡，对于新插入的值需要做大量的拆分页操作，而页的拆分需要I/O操作，为了尽可能的减少页的拆分操作，B+Tree也提供了类似于平衡二叉树的旋转功能。
  • 在多数情况下，在多个列上建立独立的索引并不能提高查询性能。理由非常简单，MySQL不知道选择哪个索引的查询效率更好
  • 当出现多个索引做联合操作时（多个OR条件），对结果集的合并、排序等操作需要耗费大量的CPU和内存资源，特别是当其中的某些索引的选择性不高，需要返回合并大量数据时，查询成本更高。
  • explain时如果发现有索引合并（Extra字段出现Using union），应该好好检查一下查询和表结构是不是已经是最优的
  • 索引选择性是指不重复的索引值和数据表的总记录数的比值
  • 唯一索引的选择性是1，这时最好的索引选择性，性能也是最好的。
  • 如果一个索引包含或者说覆盖所有需要查询的字段的值，那么就没有必要再回表查询，这就称为覆盖索引。
  • 对结果集进行排序的操作
  • 按照索引顺序扫描得出的结果自然是有序的
  • 如果explain的结果中type列的值为index表示使用了索引扫描来做排序。
  • 在设计索引时，如果一个索引既能够满足排序，有满足查询，是最好的。
  • 比如有一个索引(A,B)，再创建索引(A)就是冗余索引。
  • 对于非常小的表，简单的全表扫描更高效。对于中到大型的表，索引就非常有效。对于超大型的表，建立和维护索引的代价随之增长，这时候其他技术也许更有效，比如分区表。
  • explain后再提测是一种美德。
  • 如果要统计行数，直接使用COUNT(*)，意义清晰，且性能更好。
  • 执行EXPLAIN并不需要真正地去执行查询，所以成本非常低。
  • 确保ON和USING字句中的列上有索引。在创建索引的时候就要考虑到关联的顺序
  • 确保任何的GROUP BY和ORDER BY中的表达式只涉及到一个表中的列，这样MySQL才有可能使用索引来优化
  • MySQL关联执行的策略非常简单，它对任何的关联都执行嵌套循环关联操作，即先在一个表中循环取出单条数据，然后在嵌套循环到下一个表中寻找匹配的行，依次下去，直到找到所有表中匹配的行为为止。然后根据各个表匹配的行，返回查询中需要的各个列。
  • 最外层的查询是根据A.xx列来查询的，A.c上如果有索引的话，整个关联查询也不会使用。再看内层的查询，很明显B.c上如果有索引的话，能够加速查询，因此只需要在关联顺序中的第二张表的相应列上创建索引即可。
  • MySQL处理UNION的策略是先创建临时表，然后再把各个查询结果插入到临时表中，最后再来做查询。
  • 要使用UNION ALL，如果没有ALL关键字，MySQL会给临时表加上DISTINCT选项，这会导致整个临时表的数据做唯一性检查，这样做的代价非常高。
  • 尽可能不要使用存储过程
1 - 11 of 11
Showing 20▼ items per page