单写多读怎么玩

面试官心理分析 如果有人问到你 MQ 的知识，高可用是必问的。上一讲提到，MQ 会导致系统可用性降低。所以只要你用了 MQ，接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。 要是你傻乎乎的就干用了一个 MQ，各种问题从来没考虑过，那你就杯具了，面试官对你的感觉就是，只会简单使用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的普通小弟还凑合，要是做薪资 20k+ 的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。 面试题剖析 这个问题这么问是很好的，因为不能问你 Kafka 的高可用性怎么保证？ActiveMQ 的高可用性怎么保证？一个面试官要是这么问就显得很没水平，人家可能用的就是 RabbitMQ，没用过 Kafka，你上来问人家 Kafka 干什么？这不是摆明了刁难人么。 所以有水平的面试官，问的是 MQ 的高可用性怎么保证？这样就是你用过哪个 MQ，你就说说你对那个 MQ 的高可用性的理解。 RabbitMQ 的高可用性 RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。 RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。 单机模式 单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式。 普通集群模式（无高可用性） 普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。 而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。 所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。 镜像集群模式（高可用性） 这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。 那么如何开启这个镜像集群模式呢？其实很简单，RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。 这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！第二，这么玩儿，不是分布式的，就没有扩展性可言了，如果某个 queue 负载很重，你加机器，新增的机器也包含了这个 queue 的所有数据，并没有办法线性扩展你的 queue。你想，如果这个 queue 的数据量很大，大到这个机器上的容量无法容纳了，此时该怎么办呢？ Kafka 的高可用性 Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据。 这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。 实际上 RabbitMQ 之类的，并不是分布式消息队列，它就是传统的消息队列，只不过提供了一些集群、HA(High Availability, 高可用性) 的机制而已，因为无论怎么玩儿，RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。 Kafka 0.8 以前，是没有 HA 机制的，就是任何一个 broker 宕机了，那个 broker 上的 partition 就废了，没法写也没法读，没有什么高可用性可言。 比如说，我们假设创建了一个 topic，指定其 partition 数量是 3 个，分别在三台机器上。但是，如果第二台机器宕机了，会导致这个 topic 的 1/3 的数据就丢了，因此这个是做不到高可用的。 Kafka 0.8 以后，提供了 HA 机制，就是 replica（复制品） 副本机制。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。只能读写 leader？很简单，要是你可以随意读写每个 follower，那么就要 care 数据一致性的问题，系统复杂度太高，很容易出问题。Kafka 会均匀地将一个 partition 的所有 replica 分布在不同的机器上，这样才可以提高容错性。 这么搞，就有所谓的高可用性了，因为如果某个 broker 宕机了，没事儿，那个 broker上面的 partition 在其他机器上都有副本的。如果这个宕机的 broker 上面有某个 partition 的 leader，那么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。 写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为） 消费的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。 看到这里，相信你大致明白了 Kafka 是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要是遇上面试官确实是 Kafka 高手，深挖了问，那你只能说不好意思，太深入的你没研究过。

从业余程序员到职业程序员 程序员刚入行时，我觉得最重要的是把自己培养成职业的程序员。 我的程序员起步比同龄人都晚了很多，更不用说现在的年轻人了。我大学读的是生物专业，在上大学前基本算是完全没接触过计算机。军训的时候因为很无聊，我和室友每天跑去学校的机房玩，我现在还印象很深刻，我第一次走进机房的时候，别人问，你是要玩windows，还是dos，我那是完全的一抹黑。后来就只记得在机房一堆人都是在练习盲打，军训完，盲打倒是练的差不多了，对计算机就这么产生了浓厚的兴趣，大一的时候都是玩组装机，捣鼓了一些，对计算机的硬件有了那么一些了解。 到大二后，买了一些书开始学习当时最火的网页三剑客，学会了手写HTML、PS的基本玩法之类的，课余、暑假也能开始给人做做网站什么的(那个时候做网站真的好赚钱)，可能那样过了个一年左右，做静态的网页就不好赚钱了，也不好找实习工作，于是就开始学asp，写些简单的CRUD，做做留言板、论坛这些动态程序，应该算是在这个阶段接触编程了。 毕业后加入了深圳的一家做政府行业软件的公司，一个非常靠谱和给我空间的Leader，使得自己在那几年有了不错的成长，终于成了一个职业的程序员。 通常来说，业余或半职业的程序员，多数是1个人，或者很小的一个团队一起开发，使得在开发流程、协作工具（例如jira、cvs/svn/git等）、测试上通常会有很大的欠缺，而职业的程序员在这方面则会专业很多。另外，通常职业的程序员做的系统都要运行较长的时间，所以在可维护性上会特别注意，这点我是在加入阿里后理解更深的。一个运行10年的系统，和一个写来玩玩的系统显然是有非常大差别的。 这块自己感觉也很难讲清楚，只能说模模糊糊有个这样的概念。通常在有兴趣的基础上，从业余程序员跨越到成为职业程序员我觉得不会太难。 编程能力的成长 作为程序员，最重要的能力始终是编程能力，就我自己的感受而言，我觉得编程能力的成长主要有这么几个部分： 1、编程能力初级：会用 编程，首先都是从学习编程语言的基本知识学起的，不论是什么编程语言，有很多共同的基本知识，例如怎么写第一个Hello World、if/while/for、变量等，因此我比较建议在刚刚开始学一门编程语言的时候，看看编程语言自己的一些文档就好，不要上来就去看一些高阶的书。我当年学Java的时候上来就看Think in Java、Effective Java之类的，真心好难懂。 除了看文档以外，编程是个超级实践的活，所以一定要多写代码，只有这样才能真正熟练起来。这也是为什么我还是觉得在面试的时候让面试者手写代码是很重要的，这个过程是非常容易判断写代码的熟悉程度的。很多人会说由于写代码都是高度依赖IDE的，导致手写很难，但我绝对相信写代码写了很多的人，手写一段不太复杂的、可运行的代码是不难的。即使像我这种三年多没写过代码的人，让我现在手写一段不太复杂的可运行的Java程序，还是没问题的，前面N年的写代码生涯使得很多东西已经深入骨髓了。 我觉得编程能力初级这个阶段对于大部分程序员来说都不会是问题，勤学苦练，是这个阶段的核心。 2、编程能力中级：会查和避免问题 除了初级要掌握的会熟练的使用编程语言去解决问题外，中级我觉得首先是提升查问题的能力。 在写代码的过程中，出问题是非常正常的，怎么去有效且高效的排查问题，是程序员群体中通常能感受到的大家在编程能力上最大的差距。 解决问题能力强的基本很容易在程序员群体里得到很高的认可。在查问题的能力上，首先要掌握的是一些基本的调试技巧，好用的调试工具，在Java里有JDK自带的jstat、jmap、jinfo，不在JDK里的有mat、gperf、btrace等。工欲善其事必先利其器，在查问题上是非常典型的，有些时候大家在查问题时的能力差距，有可能仅仅是因为别人比你多知道一个工具而已。 除了调试技巧和工具外，查问题的更高境界就是懂原理。一个懂原理的程序员在查问题的水平上和其他程序员是有明显差距的。我想很多的同学应该能感受到，有些时候查出问题的原因仅仅是因为有效的工具，知其然不知其所以然。 我给很多阿里的同学培训过Java排查问题的方法，在这个培训里，我经常也会讲到查问题的能力的培养最主要的也是熟练，多尝试给自己写一些会出问题的程序，多积极的看别人是怎么查问题的，多积极的去参与排查问题，很多最后查问题能力强的人多数仅仅是因为“无他，但手熟尔”。 我自己排查问题能力的提升主要是在2009年和2010年。那两年作为淘宝消防队（处理各种问题和故障的虚拟团队）的成员，处理了很多的故障和问题。当时消防队还有阿里最公认的技术大神——多隆，我向他学习到了很多排查问题的技巧。和他比，我排查问题的能力就是初级的那种。 印象最深刻的是一次我们一起查一个应用cpu us高的问题，我们两定位到是一段代码在某种输入参数的时候会造成cpu us高的原因后，我能想到的继续查的方法是去生产环境抓输入参数，然后再用参数来本地debug看是什么原因。但多隆在看了一会那段代码后，给了我一个输入参数，我拿这个参数一运行，果然cpu us很高！这种case不是一次两次。所以我经常和别人说，我是需要有问题场景才能排查出问题的，但多隆是完全有可能直接看代码就能看出问题的，这是本质的差距。 除了查问题外，更厉害的程序员是在写代码的过程就会很好的去避免问题。大家最容易理解的就是在写代码时处理各种异常情况，这里通常也是造成程序员们之间很大的差距的地方。 写一段正向逻辑的代码，大部分情况下即使有差距，也不会太大，但在怎么很好的处理这个过程中有可能出现的异常上，这个时候的功力差距会非常明显。很多时候一段代码里处理异常逻辑的部分都会超过正常逻辑的代码量。 我经常说，一个优秀程序员和普通程序员的差距，很多时候压根就不需要看什么满天飞的架构图，而只用show一小段的代码就可以。 举一个小case大家感受下。当年有一个严重故障，最后查出的原因是输入的参数里有一个是数组，把这个数组里的值作为参数去查数据库，结果前面输入了一个很大的数组，导致从数据库查了大量的数据，内存溢出了，很多程序员现在看都会明白对入参、出参的保护check，但类似这样的case我真的碰到了很多。 在中级这个阶段，我会推荐大家尽可能的多刻意的去培养下自己这两个方面的能力，成为一个能写出高质量代码、有效排查问题的优秀程序员。 3、编程能力高级：懂高级API和原理 就我自己的经历而言，我是在写了多年的Java代码后，才开始真正更细致的学习和掌握Java的一些更高级的API，我相信多数Java程序员也是如此。 我算是从2003年开始用Java写商业系统的代码，但直到在2007年加入淘宝后，才开始非常认真地学习Java的IO通信、并发这些部分的API。尽管以前也学过也写过一些这样的代码，但完全就是皮毛。当然，这些通常来说有很大部分的原因会是工作的相关性，多数的写业务系统的程序员可能基本就不需要用到这些，所以导致会很难懂这些相对高级一些的API，但这些API对真正的理解一门编程语言，我觉得至关重要。 在之前的程序员成长路线的文章里我也讲到了这个部分，在没有场景的情况下，只能靠自己去创造场景来学习好。我觉得只要有足够的兴趣，这个问题还是不大的，毕竟现在有各种开源，这些是可以非常好的帮助自己创造机会学习的，例如学Java NIO，可以自己基于NIO包一个框架，然后对比Netty，看看哪些写的是不如Netty的，这样会非常有助于真正的理解。 在学习高级API的过程中，以及排查问题的过程中，我自己越来越明白懂编程语言的运行原理是非常重要的，因此我到了后面的阶段开始学习Java的编译机制、内存管理、线程机制等。对于我这种非科班出身的而言，学这些会因为缺乏基础更难很多，但这些更原理性的东西学会了后，对自己的编程能力会有质的提升，包括以后学习其他编程语言的能力，学这些原理最好的方法我觉得是先看看一些讲相关知识的书，然后去翻看源码，这样才能真正的更好的掌握，最后是在以后写代码的过程中、查问题的过程中多结合掌握的原理，才能做到即使在N年后也不会忘。 在编程能力的成长上，我觉得没什么捷径。我非常赞同1万小时理论，在中级、高级阶段，如果有人指点或和优秀的程序员们共事，会好非常多。不过我觉得这个和读书也有点像，到了一定阶段后（例如高中），天分会成为最重要的分水岭，不过就和大部分行业一样，大部分的情况下都还没到拼天分的时候，只需要拼勤奋就好。 系统设计能力的成长 除了少数程序员会进入专深的领域，例如Linux Kernel、JVM，其他多数的程序员除了编程能力的成长外，也会越来越需要在系统设计能力上成长。 通常一个编程能力不错的程序员，在一定阶段后就会开始承担一个模块的工作，进而承担一个子系统、系统、跨多领域的更大系统等。 我自己在工作的第三年开始承担一个流程引擎的设计和实现工作，一个不算小的系统，并且也是当时那个项目里的核心部分。那个阶段我学会了一些系统设计的基本知识，例如需要想清楚整个系统的目标、模块的划分和职责、关键的对象设计等，而不是上来就开始写代码。但那个时候由于我是一个人写整个系统，所以其实对设计的感觉并还没有那么强力的感觉。 在那之后的几年也负责过一些系统，但总体感觉好像在系统设计上的成长没那么多，直到在阿里的经历，在系统设计上才有了越来越多的体会。（点击文末阅读原文，查看：我在系统设计上犯过的14个错，可以看到我走的一堆的弯路）。 在阿里有一次做分享，讲到我在系统设计能力方面的成长，主要是因为三段经历，负责专业领域系统的设计 -> 负责跨专业领域的专业系统的设计 -> 负责阿里电商系统架构级改造的设计。 第一段经历，是我负责HSF。HSF是一个从0开始打造的系统，它主要是作为支撑服务化的框架，是个非常专业领域的系统，放在整个淘宝电商的大系统来看，其实它就是一个很小的子系统，这段经历里让我最深刻的有三点： 1).要设计好这种非常专业领域的系统，专业的知识深度是非常重要的。我在最早设计HSF的几个框的时候，是没有设计好服务消费者/提供者要怎么和现有框架结合的，在设计负载均衡这个部分也反复了几次，这个主要是因为自己当时对这个领域掌握不深的原因造成的; 2). 太技术化。在HSF的阶段，出于情怀，在有一个版本里投入了非常大的精力去引进OSGi以及去做动态化，这个后来事实证明是个非常非常错误的决定，从这个点我才真正明白在设计系统时一定要想清楚目标，而目标很重要的是和公司发展阶段结合； 3). 可持续性。作为一个要在生产环境持续运行很多年的系统而言，怎么样让其在未来更可持续的发展，这个对设计阶段来说至关重要。这里最low的例子是最早设计HSF协议的时候，协议头里竟然没有版本号，导致后来升级都特别复杂；最典型的例子是HSF在早期缺乏了缺乏了服务Tracing这方面的设计，导致后面发现了这个地方非常重要后，全部落地花了长达几年的时间；又例如HSF早期缺乏Filter Chain的设计，导致很多扩展、定制化做起来非常不方便。 第二段经历，是做T4。T4是基于LXC的阿里的容器，它和HSF的不同是，它其实是一个跨多领域的系统，包括了单机上的容器引擎，容器管理系统，容器管理系统对外提供API，其他系统或用户通过这个来管理容器。这个系统发展过程也是各种犯错，犯错的主要原因也是因为领域掌握不深。在做T4的日子里，学会到的最重要的是怎么去设计这种跨多个专业领域的系统，怎么更好的划分模块的职责，设计交互逻辑，这段经历对我自己更为重要的意义是我有了做更大一些系统的架构的信心。 第三段经历，是做阿里电商的异地多活。这对我来说是真正的去做一个巨大系统的架构师，尽管我以前做HSF的时候参与了淘宝电商2.0-3.0的重大技术改造，但参与和自己主导是有很大区别的，这个架构改造涉及到了阿里电商众多不同专业领域的技术团队。在这个阶段，我学会的最主要的： 1). 子系统职责划分。在这种超大的技术方案中，很容易出现某些部分的职责重叠和冲突，这个时候怎么去划分子系统，就非常重要了。作为大架构师，这个时候要从团队的职责、团队的可持续性上去选择团队； 2). 大架构师最主要的职责是控制系统风险。对于这种超大系统，一定是多个专业领域的架构师和大架构师共同设计，怎么确保在执行的过程中对于系统而言最重要的风险能够被控制住，这是我真正的理解什么叫系统设计文档里设计原则的部分。 设计原则我自己觉得就是用来确保各个子系统在设计时都会遵循和考虑的，一定不能是虚的东西，例如在异地多活架构里，最重要的是如何控制数据风险，这个需要在原则里写上，最基本的原则是可接受系统不可用，但也要保障数据一致，而我看过更多的系统设计里设计原则只是写写的，或者千篇一律的，设计原则切实的体现了架构师对目标的理解（例如当时异地多活这个其实开始只是个概念，但做到什么程度才叫做到异地多活，这是需要解读的，也要确保在技术层面的设计上是达到了目标的），技术方案层面上的选择原则，并确保在细节的设计方案里有对于设计原则的承接以及执行； 3). 考虑问题的全面性。像异地多活这种大架构改造，涉及业务层面、各种基础技术层面、基础设施层面，对于执行节奏的决定要综合考虑人力投入、机器成本、基础设施布局诉求、稳定性控制等，这会比只是做一个小的系统的设计复杂非常多。 系统设计能力的成长，我自己觉得最重要的一是先在一两个技术领域做到专业，然后尽量扩大自己的知识广度。例如除了自己的代码部分外，还应该知道具体是怎么部署的，部署到哪去了，部署的环境具体是怎么样的，和整个系统的关系是什么样的。 像我自己，是在加入基础设施团队后才更加明白有些时候软件上做的一个决策，会导致基础设施上巨大的硬件、网络或机房的投入，但其实有可能只需要在软件上做些调整就可以避免，做做研发、做做运维可能是比较好的把知识广度扩大的方法。 第二点是练习自己做tradeoff的能力，这个比较难，做tradeoff这事需要综合各种因素做选择，但这也是所有的架构师最关键的，可以回头反思下自己在做各种系统设计时做出的tradeoff是什么。这个最好是亲身经历，听一些有经验的架构师分享他们选择背后的逻辑也会很有帮助，尤其是如果恰好你也在同样的挑战阶段，光听最终的架构结果其实大多数时候帮助有限。 技术Leader我觉得最好是能在架构师的基础上，后续注重成长的方面还是有挺大差别，就不在这篇里写了，后面再专门来写一篇。 程序员金字塔 我认为程序员的价值关键体现在作品上，被打上作品标签是一种很大的荣幸，作品影响程度的大小我觉得决定了金字塔的层次，所以我会这么去理解程序员的金字塔。 当然，要打造一款作品，仅有上面的两点能力是不够的，作品里很重要的一点是对业务、技术趋势的判断。 希望作为程序员的大伙，都能有机会打造一款世界级的作品，去为技术圈的发展做出贡献。 由于目前IT技术更新速度还是很快的，程序员这个行当是特别需要学习能力的。我一直认为，只有对程序员这个职业真正的充满兴趣，保持自驱，才有可能在这个职业上做好，否则的话是很容易淘汰的。 作者简介： 毕玄，2007年加入阿里，十多年来主要从事在软件基础设施领域，先后负责阿里的服务框架、Hbase、Sigma、异地多活等重大的基础技术产品和整体架构改造。

这个似乎是没办法。 看这段： 在图片上传部分，其实能玩的花样很少，但是编写代码所消耗的时间最多。现在我们再假设一种情景，如果我们的图片服务器前端采用Nginx，上传功能 用PHP实现，需要写的代码很少，但是性能如何呢，答案是很差。首先PHP接收到Nginx传过来的请求后，会根据http协议（RFC1867）分离出 其中的二进制文件，存储在一个临时目录里，等我们在PHP代码里使用$_FILES["upfile"][tmp_name]获取到文件后计算MD5再存 储到指定目录，在这个过程中有一次读文件一次写文件是多余的，其实最好的情况是我们拿到http请求中的二进制文件（最好在内存里），直接计算MD5然后存储。 于是我去阅读了PHP的源代码，自己实现了POST文件的解析，让http层直接和存储层连在了一起，提高了上传图片的性能。关于RFC1867的内容和PHP是如何处理的，感兴趣的读者可以去搜索了解下，这里推荐@Laruence的文章《PHP文件上传源码分析(RFC1867) 》。 除了POST请求这个例子，zimg代码中有多处都体现了这种“减少磁盘I/O，尽量在内存中读写”和“避免内存复制”的思想，一点点的积累，最终将会带来优秀的表现。 http://www.wingdevops.com/?p=291 ######只能针对原始请求写一个HTTP处理程序了，用nginx路由过来单独处理。######大哥出手果然不同，就你知道我在乱七八糟说了些啥，哈哈。######php:input//###### 引用来自“大灰狼wow”的评论php:input// 这个恰好对付不了上传文件的表单######这也算是一个思路，传文件的请求可以由应用程序发起纯POST的。###### 如果只是统计行数的话……为啥不直接用个flash解决 ######要的效果是文件传给PHP，PHP统计出结果。这个是需求。 我说的最优方案是针对这个需求的。###### 楼主理解错了！ 上传文件第一步是 由 浏览器把 本地文件上传到服务器的临时文件夹，文件上传中，PHP操作文件的时候，文件已经传完了（此时文件在临时文件中）,PHP只是把临时文件移动到上传目录，所以这个以web的方式来说是实现不了的。（根本原因是上传文件这个过程压根没PHP的事，传完了PHP才来做事） ######这位仁兄说得在理，看看其它看官怎么说。######html5不是允许将文件分片上传吗？ 自己切割成5m一个的包呗。######mark######是这样，最近也遇到这样的问题，貌似php是无法读取到浏览器上传文件的文件流的，只能等浏览器把文件流传送到服务器，以临时文件保存，这时候php才去处理的。。。###### 引用来自“杨佰”的评论是这样，最近也遇到这样的问题，貌似php是无法读取到浏览器上传文件的文件流的，只能等浏览器把文件流传送到服务器，以临时文件保存，这时候php才去处理的。。。 这个问题可能要绕过php了

回 2楼(zc_0101) 的帖子 您好，       您的问题非常好，SQL SERVER提供了很多关于I/O压力的性能计数器，请选择性能计算器PhysicalDisk（LogicalDisk），根据我们的经验，如下指标的阈值可以帮助你判断IO是否存在压力： 1.  % Disk Time ：这个是磁盘时间百分比，这个平均值应该在85%以下 2.  Current Disk Queue Length：未完成磁盘请求数量，这个每个磁盘平均值应该小于2. 3.  Avg. Disk Queue Length：磁盘请求队列的平均长度，这个每个磁盘平均值也应该小于2 4.  Disk Transfers/sec：每次磁盘传输数量，这个每个磁盘的最大值应该小于100 5.  Disk Bytes/sec：每次磁盘传入字节数，这个在普通的磁盘上应该在10M左右 6.  Avg. Disk Sec/Read：从磁盘读取的平均时间，这个平均值应该小于10ms(毫秒) 7.  Avg. Disk Sec/Write：磁盘写入的平均时间，这个平均值也应该小于10ms(毫秒) 以上，请根据自己的磁盘系统判断，比如传统的机械臂磁盘和SSD有所不同。 一般磁盘的优化方向是： 1. 硬件优化：比如使用更合理的RAID阵列，使用更快的磁盘驱动器，添加更多的内存 2. 数据库设置优化：比如创建多个文件和文件组，表的INDEX和数据放到不同的DISK上，将数据库的日志放到单独的物理驱动器，使用分区表 3. 数据库应用优化：包括应用程序的设计，SQL语句的调整，表的设计的合理性，INDEX创建的合理性，涉及的范围很广 希望对您有所帮助，谢谢！ ------------------------- 回 3楼(鹰舞) 的帖子 您好，      根据您的描述，由于查询产生了副本REDO LOG延迟，出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁： 架构锁分成两类： 1. SCH-M：架构更改锁，主要发生在数据库SCHEMA的修改上，从你的描述看，没有更改SCHEMA，那么可以排除这个因素 2. SCH-S：架构稳定锁，主要发生在数据库的查询编译等活动 根据你的情况，应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息，未参数化的SQL语句等等 对于INDEX和SQL语句方面应，我想应该不会有太多问题。 我们重点关注一下统计信息：SQL SERVER 2012 AG副本的统计信息维护有两种： 1. 主体下发到副本 2. 临时统计信息存储在TEMPDB 对于主体下发的，我们可以设置统计信息的更新行为，自动更新时，可以设置为异步的（自动更新统计信息必须首先打开）： USE [master] GO ALTER DATABASE [Test_01]     SET AUTO_UPDATE_STATISTICS_ASYNC ON WITH NO_WAIT GO 这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。 对于临时统计信息存储在TEMPDB里面也是很重要的，再加上ALWAYSON的副本数据库默认是快照隔离，优化TEMPDB也是必要的，关于优化TEPDB这个我想大部分都知道，这里只是提醒一下。 除了从统计信息本身来解决，在查询过程中，可以降低查询的时间，以尽量减少LOCK的时间和范围，这需要优化你的SQL语句或者应用程序。 以上，希望对您有所帮助。谢谢！ ------------------------- 回 4楼(leamonjxl) 的帖子 这是一个关于死锁的问题，为了能够提供帮助一些。请根据下列建议进行： 1.    跟踪死锁 2.    分析死锁链和原因 3.    一些解决办法 关于跟踪死锁，我们首先需要打开1222标记，例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息： 如果发生了死锁，需要分析死锁发生的根源在哪里？我们不是很清楚你的具体发生死锁的形态是怎么样的。 关于死锁的实例也多，这里不再举例。 这里只是提出一些可以解决的思路： 1.    减少锁的争用 2.    减少资源的访问数 3.    按照相同的时间顺序访问资源 减少锁的争用，可以从几个方面入手 1.    使用锁提示，比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许，大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。 2.    调整隔离级别，使用MVCC，我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别，这样的话可以尽量读写不阻塞，只不过MVCC的ROW VERSION保存到TEMPDB下面，需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED，这些就不必了。 减少资源的访问数，可以从如下几个方面入手： 1.    使用聚集索引，非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此，如果对非聚集INDEX 操作的话，会产生两个锁，一个是基本表，一个是非聚集INDEX。而聚集INDEX就不一样，聚集INDEX的叶子页面和表的数据页面相同，他只需要一个LOCK。 2.    查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX，就不需要访问基本表。如果没有全覆盖，还会通过RID或者CLUSTER INDEX访问基本表，这样产生的LOCK可能会与其他SESSION争用。 按照相同的时间顺序访问资源： 确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问，第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK，但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。 ------------------------- 回 4楼(leamonjxl) 的帖子 两种方式看你的业务怎么应用。这里不仅是分表的问题，还可能存在分库，分服务器的问题。取决与你的架构方案。 物理分表+视图，这是一种典型的冷热数据分离的方案，大致的做法如下： 1.    保留最近3个月的数据为当前表，也即就是我们说的热数据 2.    将其他数据按照某种规则分表，比如按照年或者季度或者月，这部分是相对冷的数据 分表后，涉及到几个问题： 第一问题是，转移数据的过程，一般是晚上业务比较闲来转移，转移按照一定的规则来做，始终保持3个月，这个定时任务本身也很消耗时间 再者，关于查询部分，我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧，主库我觉得压力不会太大，主要是插入或者更新，只读需要做视图来包含全部的数据，但通过UNION ALL所有分表的数据，最后可能还是非常大，在某些情况下，性能不一定好。这个是不是业务上可以解决。比如，对于1年前的历史数据，放在单独的只读上，相对热的数据放在一起，这样压力也会减少。 分区表的话，因为涉及到10亿数据，要有好的分区方案，相对比较简单一点。但对于10亿的大表，始终是个棘手的问题，无论分多少个分区，单个服务器的资源也是有限的。可扩展性方面也存在问题，比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。 现在很多企业都在做分库分表，这些的要解决一些高并发，数据量大的问题。不知是否考虑过类似于中间件的方案，比如阿里巴巴的TDDL类似的方案，如果你有兴趣，可以查询相关资料。 ------------------------- 回 9楼(jiangnii) 的帖子 阿里云数据库不仅提供一个数据库，还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署，还提供了数据库高可用性架构，备份服务，性能诊断服务，监控服务，专家服务等等，保证用户放心、方便、省心地使用数据库，就像水电一样。以前的运维繁琐的事，全部由阿里云接管，用户只需要关注数据库的使用和具体的业务就好。 关于优化和在云数据库上处理大数据量或复杂的数据操作方面，在云数据库上是一样的，没有什么特别的地方，不过我们的云数据库是使用SSD磁盘，这个比普通的磁盘要快很多，IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务，比如索引诊断，连接诊断，容量分析，空间诊断等等，这些工作可能是专业的DBA才能完成的，以后我们会提供自动化的服务来为客户创造价值，希望能帮助到客户。 谢谢！ ------------------------- 回 12楼(daniellin17) 的帖子 这个问题我不知道是否是两个问题，一个是并行度，另一个是并发，我更多理解是吞吐量，单就并行度而言。 提高并行度需要考虑的因素有： 1.    可用于SQL SERVER的CPU数量 2.    SQL SERVER的版本（32位/64位） 3.    可用内存 4.    执行的查询类型 5.    给定的流中处理的行数 6.    活动的并发连接数量 7.    sys.configurations参数：affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism 以DOP的参数控制并行度为例，设置如下： SELECT * FROM sys.configurations WITH (NOLOCK) WHERE name = 'max degree of parallelism' EXEC sp_configure 'max degree of parallelism',2 RECONFIGURE WITH OVERRIDE 经过测试，DOP设置为2是一个比较适中的状态，特别是OLTP应用。如果设置高了，会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是：CXPACKET 你可以用下列语句去测试： DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR) SELECT * FROM sys.dm_os_wait_stats WITH (NOLOCK) ORDER BY 2 DESC ,3 DESC 如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话，大多根据业务量来预估，然后考虑以下： 1.    RAID的划分，RAID1适合存放事务日志文件(顺序写)，RAID10/RAID5适合做数据盘,RAID10是条带化并镜像，RAID5条带化并奇偶校验 2.    数据库设置，比如并行度，连接数，BUFFER POOL 3.    数据库文件和日志文件的存放规则，数据库文件的多文件设置规则 4.    TEMPDB的优化原则，这个很重要的 5.    表的设计方面根据业务类型而定 6.    CLUSTERED INDEX和NONCLUSTERED INDEX的设计 7.    阻塞分析 8.    锁和死锁分析 9.    执行计划缓冲分析 10.    存储过程重编译 11.    碎片分析 12.    查询性能分析,这个有很多可以优化的方式，比如OR/UNION/类型转换/列上使用函数等等 我这里列举一个高并发的场景： 比如，我们的订单，比如搞活动的时候，订单刷刷刷地增长，单个实例可能每秒达到很高很高，我们分析到最后最常见的问题是HOT PAGE问题，其等待类型是PAGE LATCH竞争。这个过程可以这么来处理，简单列几点，可以参考很多涉及高并发的案例： 1.    数据库文件和日志文件分开，存放在不同的物理驱动器磁盘上 2.    数据库文件需要与CPU个数形成一定的比例 3.    表设计可以使用HASH来作为表分区 4.    表可以设置无序的KEY/INDEX，比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX 5.    我们不能将自增列设计为聚集INDEX 这个场景只是针对高并发的插入。对于查询而言，是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。 ------------------------- 回 13楼(zuijh) 的帖子 ECS上现在有两种磁盘，一种是传统的机械臂磁盘，另一种是SSD，请先诊断你的IO是否出现了问题，本帖中有提到如何判断磁盘出现问题的相关话题，请参考。如果确定IO出现问题，可以尝试使用ECS LOCAL SSD。当然，我们欢迎你使用云数据库的产品，云数据库提供了很多有用的功能，比如高可用性，灵活的备份方案，灵活的弹性方案，实用的监控报警等等。 ------------------------- 回 17楼(豪杰本疯子) 的帖子 我们单个主机或者单个实例的资源总是有限的，因为涉及到很大的数据量，对于存储而言是个瓶颈，我曾使用过SAN和SAS存储，SAN存储的优势确实可以解决数据的灵活扩展，但是SAN也分IPSAN和FIBER SAN，如果IPSAN的话，性能会差一些。即使是FIBER SAN，也不是很好解决性能问题，这不是它的优势，同时，我们所有DB SERVER都连接到SAN上，如果SAN有问题，问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大，是造成性能问题的直接原因，因为我们不管怎么优化，一旦数据量太大，优化的能力总是有限的，所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。 所以现在很多企业在向分布式系统发展，对于数据库而言，其实有很多形式。我们最常见的是读写分离，比如SQL SERVER而言，我们可以通过复制来完成读写分离，SQL SERVER 2012及以后的版本，我们可以使用ALWAYSON来实现读写分离，但这只能解决性能问题，那空间问题怎么解决。我们就涉及到分库分表，这个分库分表跟应用结合得紧密，现在很多公司通过中间件来实现，比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分，那么DB也可以由此拆分开来。举个简单例子，我们一个典型的电子商务系统，有订单，有促销，有仓库，有配送，有财务，有秒杀，有商品等等，很多公司在初期，都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后，就会出现性能和硬件资源问题，这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。 ------------------------- 回 21楼(dt) 的帖子 问： 求大数据量下mysql存储，优化方案 分区好还是分表好，分的过程中需要考虑事项 mysql高并发读写的一些解决办法 答： 分区：对于应用来说比较简单,改造较少 分表: 应用需较多改造，优点是数据量太大的情况下，分表可以拆分到多个实例上，而分区不可以。 高并发优化,有两个建议: 1.    优化事务逻辑 2.    解决mysql高并发热点,这个可以看看阿里的一个热点补丁: http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f ------------------------- 回 23楼(aelven) 的帖子 对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势，比如磁盘是性能超好的SSD，自动转移的高可用性，没有任何单点，自动灵活的备份方案，实用的监控报警，性能监控服务等等，省去DBA很多基础性工作。 你第二个问题，看起来是一个高并发的场景，这种高并发的场景容易出现大量的LOCK甚至死锁，我不是很清楚你的业务，但可以建议一下，首先可以考虑快照隔离级别，实现行多版本控制，让读写不要阻塞。至于写写过程，需要加锁的粒度降低最低，同时这种高并发也容易出现死锁，关于死锁的分析，本帖有提到，请关注。 第三个问题，你用ECS搭建自己的应用也是可以的，RDS数据库提供了很多功能，上面已经讲到了。安全问题一直是我们最看重的问题，肯定有超好的防护的。 ------------------------- 回 26楼(板砖大叔) 的帖子 我曾经整理的关于索引的设计与规范，可以供你参考： ----------------------------------------------------------------------- 索引设计与规范 1.1    使用索引 SQL SERVER没有索引也可以检索数据，只不过检索数据时扫描这个表而异。存储数据的目的，绝大多数都是为了再次使用，而一般数据检索都是带条件的检索，数据查询在数据库操作中会占用较大的比例，提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构，最小优化了定位所需要的键值的访问页面量，包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起，它决定表中数据存储的物理顺序，其叶子节点为数据行。 1.2    聚集索引 1.2.1    关于聚集索引 没聚集索引的表叫堆。堆是一种没有加工的数据，以行标示符作为指向数据存储位置的指针，数据没有顺序。聚集索引的叶子页面和表的数据页面相同，因此表行物理上按照聚集索引列排序，表数据的物理顺序只有一种，所以一个表只有一个聚集索引。 1.2.2    与非聚集索引关系 非聚集索引的一个索引行包含指向表对应行的指针，这个指针称为行定位器，行定位器的值取决于数据页保存为堆还是被聚集。若是堆，行定位器指向的堆中数据行的行号指针，若是聚集索引表，行定位器是聚集索引键值。 1.2.3    设计聚集索引注意事项     首先创建聚集索引     聚集索引上的列需要足够短     一步重建索引，不要使用先DROP再CREATE，可使用DROP_EXISTING     检索一定范围和预先排序数据时使用，因为聚集索引的叶子与数据页面相同，索引顺序也是数据物理顺序，读取数据时，磁头是按照顺序读取，而不是随机定位读取数据。     在频繁更新的列上不要设计聚集索引，他将导致所有的非聚集所有的更新，阻塞非聚集索引的查询     不要使用太长的关键字，因为非聚集索引实际包含了聚集索引值     不要在太多并发度高的顺序插入，这将导致页面分割，设置合理的填充因子是个不错的选择 1.3    非聚集索引 1.3.1    关于非聚集索引 非聚集索引不影响表页面中数据的顺序，其叶子页面和表的数据页面时分离的，需要一个行定位器来导航数据，在将聚集索引时已经有说明，非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型，比如覆盖索引，过滤索引等。 1.3.2    设计非聚集索引     频繁更新的列，不适合做聚集索引，但可以做非聚集索引     宽关键字，例如很宽的一列或者一组列，不适合做聚集索引的列可作非聚集索引列     检索大量的行不宜做非聚集索引，但是可以使用覆盖索引来消除这种影响 1.3.3    优化书签查找 书签会访问索引之外的数据，在堆表，书签查找会根据RID号去访问数据，若是聚集索引表，一般根据聚集索引去查找。在查询数据时，要分两个部分来完成，增加了读取数据的开销，增加了CPU的压力。在大表中，索引页面和数据页面一般不会临近，若数据只存在磁盘，产生直接随机从磁盘读取，这导致更多的消耗。因此，根据实际需要优化书签查找。解决书签查找有如下方法：     使用聚集索引避免书签查找     使用覆盖索引避免书签查找     使用索引连接避免数据查找 1.4    聚集与非聚集之比较 1.4.1    检索的数据行 一般地，检索数据量大的一般使用聚集索引，因为聚集索引的叶子页面与数据页面在相同。相反，检索少量的数据可能非聚集索引更有利，但注意书签查找消耗资源的力度，不过可考虑覆盖索引解决这个问题。 1.4.2    数据是否排序 如果数据需要预先排序，需要使用聚集索引，若不需要预先排序就那就选择聚集索引。 1.4.3    索引键的宽度 索引键如果太宽，不仅会影响数据查询性能，还影响非聚集索引，因此，若索引键比较小，可以作为聚集索引，如果索引键够大，考虑非聚集索引，如果很大的话，可以用INCLUDE创建覆盖索引。 1.4.4    列更新的频度 列更新频率高的话，应该避免考虑所用非聚集索引，否则可考虑聚集索引。 1.4.5    书签查找开销 如果书签查找开销较大，应该考虑聚集索引，否则可使用非聚集索引，更佳是使用覆盖索引，不过得根据具体的查询语句而看。 1.5    覆盖索引 覆盖索引可显著减少查询的逻辑读次数，使用INCLUDE语句添加列的方式更容易实现，他不仅减小索引中索引列的数据，还可以减少索引键的大小，原因是包含列只保存在索引的叶子级别上，而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生，与聚集索引类似，因为聚集索引值发生一次锁，非覆盖索引可能发生两次，一次锁数据，一次锁索引，以确保数据的一致性。覆盖索引相当于数据的一个拷贝，与数据页面隔离，因此也只发生一次锁。 1.6    索引交叉 如果一个表有多个索引，那么可以拥有多个索引来执行一个查询，根据每个索引检索小的结果集，然后就将子结果集做一个交叉，得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。 1.7    索引连接 几乎是跟索引交叉类似，是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询，SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。 1.8    过滤索引 用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效，创建索引时，可以像写T-SQL语句一样加个WHERE条件，以排除某部分数据而检索。 1.9    索引视图 索引视图在OLAP系统上可能有胜算，在OLTP会产生过大的开销和不可操作性，比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构，索引视图要求企业版，这些限制导致不可操作性。 1.10    索引设计建议 1.10.1    检查WHERE字句和连接条件列 检查WHERE条件列的可选择性和数据密度，根据条件创建索引。一般地，连接条件上应当考虑创建索引，这个涉及到连接技术，暂时不说明。 1.10.2    使用窄的索引 窄的索引有可减少IO开销，读取更少量的数据页。并且缓存更少的索引页面，减少内存中索引页面的逻辑读取大小。当然，磁盘空间也会相应地减少。 1.10.3    检查列的唯一性 数据分布比较集中的列，种类比较少的列上创建索引的有效性比较差，如果性别只有男女之分，最多还有个UNKNOWN，单独在上面创建索引可能效果不好，但是他们可以为覆盖索引做出贡献。 1.10.4    检查列的数据类型 索引的数据类型是很重要的，在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型，在数据长度较小的类型上创建又比在长度较长的类型上更有效。 1.10.5    考虑列的顺序 对于包含多个列的索引，列顺序很重要。索引键值在索引上的第一上排序，然后在前一列的每个值的下一列做子排序，符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性，列宽度，列的数据类型来做权衡。 1.10.6    考虑索引的类型 使用索引类型前面已经有较多的介绍，怎么选择已经给出。不再累述。 ------------------------- 回 27楼(板砖大叔) 的帖子 这两种都可以吧。看个人的喜好，不过微软现在的统一风格是下划线，比如表sys.all_columns/sys.tables，然后你再看他的列全是下划线连接，name     /object_id    /principal_id    /schema_id    /parent_object_id      /type    /type_desc    /create_date    /modify_date 我个人的喜好也是喜欢下划线。    

回2楼啊里新人的帖子 在日常的业务开发中，常见使用到索引的地方大概有两类： 第一类.做业务约束需求，比如需要保证表中每行的单个字段或者某几个组合字段是唯一的，则可以在表中创建唯一索引; 比如：需要保证test表中插入user_id字段的值不能出现重复，则在设计表的时候，就可以在表中user_id字段上创建一个唯一索引： CREATE TABLE `test` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `user_id` int(11) NOT NULL,   `gmt_create` datetime DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `uk_userid` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ; 第二类.提高SQL语句执行速度，可以根据SQL语句的查询条件在表中创建合适的索引，以此来提升SQL语句的执行速度； 此过程好比是去图书找一本书，最慢的方法就是从图书馆的每一层楼每一个书架一本本的找过去；快捷一点的方法就是先通过图书检索来确认这一本书在几楼那个书架上，然后直接去找就可以了；当然创建这个索引也需要有一定的代价，需要存储空间来存放，需要在数据行插入，更新，删除的时候维护索引： 例如： CREATE TABLE `test_record` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `user_id` int(11) NOT NULL,   `gmt_create` datetime DEFAULT NULL,   PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5635996 DEFAULT CHARSET=utf8 该表有500w的记录，我需要查询20:00后插入的记录有多少条记录： mysql> select count(*) from test_record where gmt_create>'2014-12-17 20:00:00'; +----------+ | count(*) | +----------+ |        1 | +----------+ 1 row in set (1.31 sec) 可以看到查询耗费了1.31秒返回了1行记录，如果我们在gmt_create字段上添加索引： mysql> alter table test_record add index ind_gmt_create(gmt_create); Query OK, 0 rows affected (21.87 sec) Records: 0  Duplicates: 0  Warnings: 0 mysql> select count(*) from test_record where gmt_create>'2014-12-17 20:00:00'; +----------+ | count(*) | +----------+ |        1 | +----------+ 1 row in set (0.01 sec) 查询只消耗了0.01秒中就返回了记录. 总的来说，为SQL语句（select，update，delete）创建必要的索引是必须的，这样虽然有一定的性能和空间消耗，但是是值得，尤其是在大并发的请求下，大量的数据被扫描造成系统IO和CPU资源消耗完，进而导致整个数据库不可服务. ------------------------- 怎么学好数据库是一个比较大题目，数据库不仅仅是写SQL那么简单，即使知道了SQL怎么写，还需要很清楚的知道这条SQL他大概扫描了多少数据，返回多少数据，是否需要创建索引。至于SQL优化是一个比较专业的技术活，但是可以通过学习是可以掌握的，你可以把一条sql从执行不出来优化到瞬间完成执行，这个过程的成就感是信心满满的。学习的方法可以有以下一些过程：1、自己查资料，包括书本，在线文档，google，别人的总结等等，试图自己解决2、多做实验，证明自己的想法以及判断3、如果实在不行，再去论坛问，或者问朋友4、如果问题解决了，把该问题的整个解决方法记录下来，以备后来的需要5、多关注别人的问题，或许以后自己就遇到了，并总是试图去多帮助别人6、习惯从多个方面去考虑问题，并且养成良好的总结习惯 下面是一些国内顶级数据库专家学习数据库的经验分享给大家： http://www.eygle.com/archives/2005/08/ecinieoracleouo.html 其实学习任何东西都是一样，没有太多的捷径可走，必须打好了坚实的基础，才有可以在进一步学习中得到快速提高。王国维在他的《人间词话》中曾经概括了为学的三种境界，我在这里套用一下： 古今之成大事业、大学问者，罔不经过三种之境界。"昨夜西风凋碧树。独上高楼，望尽天涯路。"此第一境界也。"衣带渐宽终不悔，为伊消得人憔悴。"此第二境界也。"众里寻他千百度，蓦然回首，那人却在灯火阑珊处。"此第三境界也。 学习Oracle，这也是你必须经历的三种境界。 第一层境界是说，学习的路是漫漫的，你必须做好充分的思想准备，如果半途而废还不如不要开始。 这里，注意一个"尽"字，在开始学习的过程中，你必须充分阅读Oracle的基础文档，概念手册、管理手册、备份恢复手册等（这些你都可以在http://tahiti.oracle.com 上找到）；OCP认证的教材也值得仔细阅读。打好基础之后你才具备了进一步提升的能力，万丈高楼都是由地而起。 第二层境界是说，尽管经历挫折、打击、灰心、沮丧，也都要坚持不放弃，具备了基础知识之后，你可以对自己感兴趣或者工作中遇到的问题进行深入的思考，由浅入深从来都不是轻而易举的，甚至很多时候你会感到自己停滞不前了，但是不要动摇，学习及理解上的突破也需要时间。 第三次境界是说，经历了那么多努力以后，你会发现，那苦苦思考的问题，那百思不得其解的算法原理，原来答案就在手边，你的思路豁然开朗，宛如拨云见月。这个时候，学习对你来说，不再是个难题，也许是种享受，也许成为艺术。 所以如果你想问我如何速成，那我是没有答案的。 不经一番寒彻骨，哪得梅花扑鼻香。 当然这三种境界在实际中也许是交叉的，在不断的学习中，不断有蓦然回首的收获。 我自己在学习的过程中，经常是采用"由点及面法"。 当遇到一个问题后，一定是深入下去，穷究根本，这样你会发现，一个简单的问题也必定会带起一大片的知识点，如果你能对很多问题进行深入思考和研究，那么在深处，你会发现，这些面逐渐接合，慢慢的延伸到oracle的所有层面，逐渐的你就能融会贯通。这时候，你会主动的去尝试全面学习Oracle，扫除你的知识盲点，学习已经成为一种需要。 由实践触发的学习才最有针对性，才更能让你深入的理解书本上的知识，正所谓：" 纸上得来终觉浅，绝知此事要躬行"。实践的经验于我们是至为宝贵的。 如果说有，那么这，就是我的捷径。 想想自己，经常是"每有所获，便欣然忘食"， 兴趣才是我们最好的老师。 Oracle的优化是一门学问，也是一门艺术，理解透彻了，你会知道，优化不过是在各种条件之下做出的均衡与折中。 内存、外存；CPU、IO...对这一切你都需要有充分的认识和相当的了解，管理数据库所需要的知识并不单纯。 作为一个数据库管理人员，你需要做的就是能够根据自己的知识以及经验在各种复杂情况下做出快速正确的判断。当问题出现时，你需要知道使用怎样的手段发现问题的根本；找到问题之后，你需要运用你的知识找到解决问题的方法。 这当然并不容易，举重若轻还是举轻若重，取决于你具备怎样的基础以及经验积累。 在网络上，Howard J. Rogers最近创造了一个新词组:Voodoo Tuning，用以形容那些没有及时更新自己的知识技能的所谓的Oracle技术专家。由于知识的陈旧或者理解的肤浅，他们提供的很多调整建议是错误的、容易使人误解的，甚至是荒诞的。他们提供的某些建议在有些情况下也许是正确的，如果你愿意回到Oracle5版或者6版的年代；但是这些建议在Oracle7.0,8.0 或者 Oracle8i以后往往是完全错误的。 后来基于类似问题触发了互联网内Oracle顶级高手的一系列深入讨论，TOM、Jonathan Lewis、HJR等人都参与其中，在我的网站上(www.eygle.com )上对这些内容及相关链接作了简要介绍，有兴趣的可以参考。 HJR给我们提了很好的一个提示:对你所需要调整的内容，你必须具有充分的认识，否则你做出的判断就有可能是错误的。 这也是我想给自己和大家的一个建议: 学习和研究Oracle，严谨和认真必不可少。 当然 你还需要勤奋，我所熟悉的在Oracle领域有所成就的技术人员，他们共同的特点就是勤奋。 如果你觉得掌握的东西没有别人多，那么也许就是因为，你不如别人勤奋。 要是你觉得这一切过于复杂了，那我还有一句简单的话送给大家: 不积跬步，无以至千里。学习正是在逐渐积累过程中的提高。 现在Itpub给我们提供了很好的交流场所，很多问题都可以在这里找到答案，互相讨论，互相学习。这是我们的幸运，我也因此非常感谢这个网络时代。 参考书籍： 如果是一个新人可以先买一些基本的入门书籍，比如MySQL：《 深入浅出MySQL——数据库开发、优化与管理维护 》，在进阶一点的就是《 高性能MySQL（第3版） 》 oracle的参考书籍： http://www.eygle.com/archives/2006/08/oracle_fundbook_recommand.html 最后建议不要在数据库中使用外键，让应用程序来保证。 ------------------------- Re:回 9楼(千鸟) 的帖子 我有一个问题想问问，现在在做一个与图书有关的项目，其中有一个功能是按图书书名搜索相似图书列表，问题不难，但是想优化一下，有如下问题想请教一下： 1、在图书数据库数据表的书名字段里，按图书书名进行关键字搜索，如何快速搜索相关的图书？   现在由于数据不多，直接用的like模糊查找验证功能而已； 如果数据量不大，是可以在数据库中完成搜索的，可以在搜索字段上创建索引，然后进行搜索查询： CREATE TABLE `book` (   `book_id` int(11) NOT NULL AUTO_INCREMENT,   `book_name` varchar(100) NOT NULL,   .............................   PRIMARY KEY (`book_id`),   KEY `ind_name` (`book_name`) ) ENGINE=InnoDB select book.*  from book , (select book_id from book where book_name like '%算法%')  book_search_id  where book.book_id=book_search_id.book_id; 但是当数据量变得很大后，就不在适合了，可以采用一些其他的第三方搜索技术比如sphinx； 2、如何按匹配的关键度进行快速排序？比如搜索“算法”，有一本书是《算法》，另一本书是《算法设计》，要求前者排在更前面。 现在的排序是根据数据表中的主键序号id进行的排序，没有达到想要的效果。 root@127.0.0.1 : test 15:57:12> select book_id,book_name from book_search where book_name like '%算%' order by book_name; +---------+--------------+ | book_id | book_name    | +---------+--------------+ |       2 | 算法       | |       1 | 算法设计 | ------------------------- 回 10楼(大黑豆) 的帖子 模糊查询分为半模糊和全模糊，也就是： select * from book where name like 'xxx%';(半模糊) select * from book where name like '%xxx%';(全模糊) 半模糊可以可以使用到索引，全模糊在上面场景是不能使用到索引的，但可以进行一些改进，比如： select book.*  from book , (select book_id from book where book_name like '%算法%')  book_search_id   where book.book_id=book_search_id.book_id; 注意这里book_id是主键，同时在book_name上创建了索引 上面的sql语句可以利用全索引扫描来完成优化，但是性能不会太好；特别在数据量大，请求频繁的业务场景下不要在数据库进行模糊查询； 非得使用数据库的话 ，建议不要在生产库进行查询，可以在只读节点进行查询，避免查询造成主业务数据库的资源消耗完，导致故障. 可以使用一些开源的搜索引擎技术，比如sphinx. ------------------------- 回 11楼(蓝色之鹰) 的帖子 我想问下,sql优化一般从那几个方面入手？多表之间的连接方式：Nested Loops，Hash Join 和 Sort Merge Join，是不是Hash Join最优连接？ SQL优化需要了解优化器原理，索引的原理，表的存储结构，执行计划等，可以买一本书来系统的进行学习，多多实验； 不同的数据库优化器的模型不一样，比如oracle支持NL，HJ，SMJ，但是mysql只支持NL，不通的连接方式适用于不同的应用场景； NL：对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择 HJ：对于列连接是做大数据集连接时的常用方式 SMJ：通常情况下散列连接的效果都比排序合并连接要好，然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接 ------------------------- Re:回 19楼(原远) 的帖子 有个问题：分类表TQueCategory，问题表TQuestion（T-SQL) CREATE TABLE TQueCategory ( ID INT IDENTITY(1,1) PRIMARY KEY,        --问题分类ID NAME VARCHAR(20)        --问题分类名称 ) CREATE TABLE TQuestion ( ID INT IDENTITY(1,1) PRIMARY KEY,        --问题ID CateID INT NOT NULL,        --问题分类ID TITLE VARCHAR(50),        --问题标题 CONTENT VARCHAR(500)        --问题内容 ) 当前要统计某个分类下的问题数，有两种方式： 1.每次统计，在TQuestion通过CateID进行分组统计 SELECT CateID,COUNT(1) AS QueNum FROM TQuestion GROUP BY CateID WHERE 1=1 2.在TQueCategory表增加字段QueNum，用于标识该分类下的问题数量 ALTER TABLE TQueCategory ADD QueNum INT SELECT CateID,QueNum FROM TQueCategory 问：在哪种业务应用场景下采用上面哪种方式性能比较好，为什么？ ############################################################################################### 方案 一 需要对 TQuestion 的 CateID字段 进行分组 ，可以在 CateID上创建一个索引，这样就可以索引扫描来完成查询； 方案 二 需要对 TQueCategory 进行扫描就可以得出结果，但是必须在问题表有插入，删除的时候维护quenum数量； 单单从SQL的性能来看， 分类表的数量应该是远远小于问题表的数量的，所以方案二的性能会比较好； 但是如果 TQuestion 的插入非常频繁的话，会带来对 TQueCategory的频繁更新，一次 TQuestion 的 insert或deleted就会带来一次 TQueCategory 的update，这个代价其实是蛮高的； 如果这个分类统计的查询不是非常频繁的话，建议还是使用方案一； 同时还可能还会其他的业务逻辑统计需求（例如： CateID +时间），这个时候在把逻辑放到 TQueCategory就不合适了。 ------------------------- 回 20楼(原远) 的帖子 经验之谈，仅供参考 使用外键在开发上确实省去了很多功夫，但是把业务逻辑交由数据库来完成，对后期的维护来说是很麻烦的事情，不利于维护. ------------------------- 回 21楼(玩站网) 的帖子 无关技术方面： 咨询一下，现在mysql新的版本，5.5.45后貌似修改了开源协议。 是否意味着今后我们商业化使用mysql将受到限制？ 如果甲骨文真周到那一步，rds是否会受到影响？ 一个疑惑： 为什么很少见到有人用mysql正则匹配？性能不好还是什么原因？ ######################################## MySQL有商业版 和 社区版，RDS的MySQL采用开源的社区版进行改进，由专门的RDS MySQL源码团队来维护，国内TOP 10的mysql源码贡献者大部分都在RDS，包括了@丁奇 ，@彭立勋 ，@印风 等； 不在数据库中做业务计算，是保证数据库运行稳定的一个好的设计经验； 是否影响性能与你的sql的执行频率，需要参与的计算数据量相关，当然了还包括数据库所在主机的IO，cpu，内存等资源，离开了这些谈性能是没有多大意义的； ------------------------- 回 22楼(比哥) 的帖子 分页该怎么优化才行？？？ ######################### 可以参考这个链接，里面有很多的最佳实践，其中就包括了分页语句的优化： http://bbs.aliyun.com/read/168647.html?spm=5176.7114037.1996646101.1.celwA1&pos=1 普通写法： select  *  from t where sellerid=100 limit 100000，20 普通limit M，N的翻页写法，往往在越往后翻页的过程中速度越慢，原因 mysql会读取表中的前M+N条数据，M越大，性能就越差： 优化写法： select t1.* from  t t1,             (select id from t  sellerid=100 limit 100000，20) t2 where t1.id=t2.id; 优化后的翻页写法，先查询翻页中需要的N条数据的主键id，在根据主键id 回表查询所需要的N条数据，此过程中查询N条数据的主键ID在索引中完成 注意：需要在t表的sellerid字段上创建索引 create index ind_sellerid on t(sellerid); 案例： user_A (21:42:31): 这个sql该怎么优化，执行非常的慢： | Query   |   51 | Sending data | select id, ... from t_buyer where sellerId = 765922982 and gmt_modified >= '1970-01-01 08:00:00' and gmt_modified <= '2013-06-05 17:11:31' limit 255000, 5000 SQL改写：selectt2.* from (selectid from t_buyer where sellerId = 765922982   andgmt_modified >= '1970-01-01 08:00:00'   andgmt_modified <= '2013-06-05 17:11:31' limit255000, 5000）t1,t_buyer t2 where t1.id=t2.id index：seller_id,gmt_modified user_A(21:58:43): 好像很快啊。神奇，这个原理是啥啊。牛！！！ user_A(21:59:55): 5000 rows in set (4.25 sec)， 前面要90秒。 ------------------------- 回 27楼(板砖大叔) 的帖子 这里所说的索引都是普通的b-tree索引，mysql，sqlserver，oracle 的关系数据库都是默认支持的； ------------------------- 回 32楼(veeeye) 的帖子 可以详细说明一下“最后建议不要在数据库中使用外键，让应用程序来保证。 ”的原因吗？我们公司在项目中经常使用外键，用程序来保证不是相对而言更加复杂了吗？ 这里的不建议使用外键，主要考虑到 ： 第一.维护成本上，把一些业务逻辑交由数据库来保证，当业务需求发生改动的时候，需要同时考虑应用程序和数据库，有时候一些数据库变更或者bug，可能会导致外键的失效；同时也给数据库的管理人员带来维护的麻烦，不便于管理。 第二.性能上考虑，当大量数据写入的时候，外键肯定会带来一定的性能损耗，当出现这样的问题时候，再来改造去除外键，真的就不值得了； 最后，不在数据库中参与业务的计算（存储过程，函数，触发器，外键），是保证数据库运行稳定的一个好的最佳实践。 ------------------------- 回 33楼(优雅的固执) 的帖子 ReDBA专家门诊一期：索引与sql优化 十分想请大师分享下建立索引的经验 我平时简历索引是这样的 比如订单信息的话 建立 订单号  唯一聚集索引 其他的比如   客户编号 供应商编号 商品编号 这些建立非聚集不唯一索引   ################################################## 建立索引，需要根据你的SQL语句来进行创建，不是每一个字段都需要进行创建，也不是一个索引都不创建,，可以把你的SQL语句，应用场景发出来看看。 索引的创建确实是一个非常专业的技术活，需要掌握：表的存储方式，索引的原理，数据库的优化器，统计信息，最后还需要能够读懂数据库的执行计划，以此来判断索引是否创建正确； 所以需要进行系统的学习才能掌握，附件是我在2011年的时候的一次公开课的ppt，希望对你有帮助，同时可以把你平时遇到的索引创建的疑惑发到论坛上来，大家可以一起交流。 ------------------------- 回 30楼(几几届) 的帖子 我也是这样，简单的会，仔细写也会写出来，但是就是不知道有没有更快或者更好的 #################################################### 多写写SQL，掌握SQL优化的方法，自然这些问题不在话下了。 ------------------------- 回 40楼(小林阿小林) 的帖子 mysql如何查询需要优化的语句，比如慢查询的步奏，如何找出需要通知程序员修改或者优化的sql语句 ############################################################ 可以将mysql的慢日志打开，就可以记录执行时间超过指定阀值的慢SQL到本地文件或者数据库的slow_log表中； 在RDS中默认是打开了慢日志功能的：long_query_time=1，表示会记录执行时间>=1秒的慢sql； 如何快速找到mysql瓶颈： 简单一点的方法，可以通过监控mysql所在主机的性能（CPU，IO，load等）以及mysql本身的一些状态值（connections，thread running，qps，命中率等）； RDS提供了完善的数据库监控体系，包括了CPU，IOPS，Disk，Connections，QPS，可以重点关注cpu，IO，connections，disk 4个 指标； cpu，io，connections主要体现在了性能瓶颈，disk主要体现了空间瓶颈； 有时候一条慢sql语句的频繁调用，也可能导致整个实例的cpu，io，connections达到100%；也有可能一条排序的sql语句，消耗大量的临时空间，导致实例的空间消耗完。 ------------------------- 下面是分析一个cpu 100%的案例分析：该实例的cpu已经到达100% 查看当前数据库的活动会话信息：当前数据库有较多的活跃线程在数据库中执行查看当前数据库正在执行的sql： 可以看到这条sql执行的非常缓慢：[tr=rgb(100, 204, 255)]delete from task_process where task_id='1801099' 查看这个表的索引： CREATE TABLE `task_process` (  `id` int(11) NOT NULL AUTO_INCREMENT,    ................  `task_id` int(11) NOT NULL DEFAULT '0' COMMENT '??????id',   ................  PRIMARY KEY (`id`),  KEY `index_over_task` (`is_over`,`task_id`),  KEY `index_over` (`is_over`,`is_auto`) USING BTREE,  KEY `index_process_sn` (`process_sn`,`is_over`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=32129710； 可以看到这个表有3KW的数据，但是没有task_id字段开头的索引，导致该sql语句删除需要进行全表扫描： 在我们的诊断报告中已经将该sql语句捕获到，同时给你提出该怎样进行索引的添加。 广告：诊断报告将会在1月底发布到控制台，到时候用户可以直接查看诊断建议，来完成你的数据库优化。 ------------------------- 回 45楼(dentrite) 的帖子 datetime和int都是占用数据库4个字节，所以在空间上没有什么差别；但是为了可读性，建议还是使用datetime数据类型。 ------------------------- 回 48楼(yuantel) 的帖子 麻烦把ecs_brand和ecs_goods的表结构发出来一下看看 。 ------------------------- 回 51楼(小林阿小林) 的帖子 普通的 ECS服务器上目前还没有这样的慢SQL索引建议的工具。 不过后续有IDBCloud将会集成这样的sql诊断功能，使用他来管理ECS上的数据库就可以使用这样的功能了 。