保护检测响应不可用

熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。

服务熔断 熔断机制是应对雪崩效应的一种微服务链路保护机制。 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。 Hystrix服务降级 其实就是线程池中单个线程障处理，防止单个线程请求时间太长，导致资源长期被占有而得不到释放，从而导致线程池被快速占用完，导致服务崩溃。 Hystrix能解决如下问题： 请求超时降级，线程资源不足降级，降级之后可以返回自定义数据 线程池隔离降级，分布式服务可以针对不同的服务使用不同的线程池，从而互不影响 自动触发降级与恢复 实现请求缓存和请求合并

服务降级 整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来 服务熔断 熔断机制是应对雪崩效应的一种微服务链路保护机制。 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。 服务限流 接近实时的监控 除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

能干的多了去了看下面弹性计算云服务器ECS：可弹性扩展、安全、稳定、易用的计算服务块存储：可弹性扩展、高性能、高可靠的块级随机存储专有网络 VPC：帮您轻松构建逻辑隔离的专有网络负载均衡：对多台云服务器进行流量分发的负载均衡服务弹性伸缩：自动调整弹性计算资源的管理服务资源编排：批量创建、管理、配置云计算资源容器服务：应用全生命周期管理的Docker服务高性能计算HPC：加速深度学习、渲染和科学计算的GPU物理机批量计算：简单易用的大规模并行批处理计算服务E-MapReduce：基于Hadoop/Spark的大数据处理分析服务数据库云数据库RDS：完全兼容MySQL，SQLServer，PostgreSQL云数据库MongoDB版：三节点副本集保证高可用云数据库Redis版：兼容开源Redis协议的Key-Value类型云数据库Memcache版：在线缓存服务，为热点数据的访问提供高速响应PB级云数据库PetaData：支持PB级海量数据存储的分布式关系型数据库云数据库HybridDB：基于Greenplum Database的MPP数据仓库云数据库OceanBase：金融级高可靠、高性能、分布式自研数据库数据传输：比GoldenGate更易用，阿里异地多活基础架构数据管理：比phpMyadmin更强大，比Navicat更易用存储对象存储OSS：海量、安全和高可靠的云存储服务文件存储：无限扩展、多共享、标准文件协议的文件存储服务归档存储：海量数据的长期归档、备份服务块存储：可弹性扩展、高性能、高可靠的块级随机存储表格存储：高并发、低延时、无限容量的Nosql数据存储服务网络CDN：跨运营商、跨地域全网覆盖的网络加速服务专有网络 VPC：帮您轻松构建逻辑隔离的专有网络高速通道：高速稳定的VPC互联和专线接入服务NAT网关：支持NAT转发、共享带宽的VPC网关大数据（数加）MaxCompute：原名ODPS，是一种快速、完全托管的TB/PB级数据仓库解决方案大数据开发套件：提供可视化开发界面、离线任务调度运维、快速数据集成、多人协同工作等功能，拥有强大的Open API为数据应用开发者提供良好的再创作生态DataV数据可视化：专精于业务数据与地理信息融合的大数据可视化，通过图形界面轻松搭建专业的可视化应用， 满足您日常业务监控、调度、会展演示等多场景使用需求关系网络分析：基于关系网络的大数据可视化分析平台，针对数据情报侦察场景赋能，如打击虚假交易，审理保险骗赔，案件还原研判等推荐引擎：推荐服务框架，用于实时预测用户对物品偏好，支持 A/B Test 效果对比公众趋势分析：利用语义分析、情感算法和机器学习，分析公众对品牌形象、热点事件和公共政策的认知趋势企业图谱：提供企业多维度信息查询，方便企业构建基于企业画像及企业关系网络的风险控制、市场监测等企业级服务数据集成：稳定高效、弹性伸缩的数据同步平台，为阿里云各个云产品提供离线(批量)数据进出通道分析型数据库：在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索流计算：流式大数据分析平台，提供给用户在云上进行流式数据实时化分析工具人工智能机器学习：基于阿里云分布式计算引擎的一款机器学习算法平台，用户通过拖拉拽的方式可视化的操作组件来进行试验，平台提供了丰富的组件，包括数据预处理、特征工程、算法组件、预测与评估语音识别与合成：基于语音识别、语音合成、自然语言理解等技术，为企业在多种实际应用场景下，赋予产品“能听、会说、懂你”式的智能人机交互体验人脸识别：提供图像和视频帧中人脸分析的在线服务，包括人脸检测、人脸特征提取、人脸年龄估计和性别识别、人脸关键点定位等独立服务模块印刷文字识别：将图片中的文字识别出来，包括身份证文字识别、门店招牌识别、行驶证识别、驾驶证识别、名片识别等证件类文字识别场景云安全（云盾）服务器安全（安骑士）：由轻量级Agent和云端组成，集检测、修复、防御为一体，提供网站后门查杀、通用Web软件0day漏洞修复、安全基线巡检、主机访问控制等功能，保障服务器安全DDoS高防IP：云盾DDoS高防IP是针对互联网服务器（包括非阿里云主机）在遭受大流量的DDoS攻击后导致服务不可用的情况下，推出的付费增值服务，用户可以通过配置高防IP，将攻击流量引流到高防IP，确保源站的稳定可靠Web应用防火墙：网站必备的一款安全防护产品。 通过分析网站的访问请求、过滤异常攻击，保护网站业务可用及资产数据安全加密服务：满足云上数据加密，密钥管理、加解密运算需求的数据安全解决方案CA证书服务：云上签发Symantec、CFCA、GeoTrust SSL数字证书，部署简单，轻松实现全站HTTPS化，防监听、防劫持，呈现给用户可信的网站访问数据风控：凝聚阿里多年业务风控经验，专业、实时对抗垃圾注册、刷库撞库、活动作弊、论坛灌水等严重威胁互联网业务安全的风险绿网：智能识别文本、图片、视频等多媒体的内容违规风险，如涉黄，暴恐，涉政等，省去90%人力成本安全管家：基于阿里云多年安全实践经验为云上用户提供的全方位安全技术和咨询服务，为云上用户建立和持续优化云安全防御体系，保障用户业务安全云盾混合云：在用户自有IDC、专有云、公共云、混合云等多种业务环境为用户建设涵盖网络安全、应用安全、主机安全、安全态势感知的全方位互联网安全攻防体系态势感知：安全大数据分析平台，通过机器学习和结合全网威胁情报，发现传统防御软件无法覆盖的网络威胁，溯源攻击手段、并且提供可行动的解决方案先知：全球顶尖白帽子和安全公司帮你找漏洞，最私密的安全众测平台。全面体检，提早发现业务漏洞及风险，按效果付费移动安全：为移动APP提供安全漏洞、恶意代码、仿冒应用等检测服务，并可对应用进行安全增强，提高反破解和反逆向能力。互联网中间件企业级分布式应用服务EDAS：以应用为中心的中间件PaaS平台、消息队列MQ：Apache RocketMQ商业版企业级异步通信中间件分布式关系型数据库服务DRDS：水平拆分/读写分离的在线分布式数据库服务云服务总线CSB：企业级互联网能力开放平台业务实施监控服务ARMS：端到端一体化实时监控解决方案产品分析E-MapReduce：基于Hadoop/Spark的大数据处理分析服务云数据库HybirdDB：基于Greenplum Database的MPP数据仓库高性能计算HPC：加速深度学习、渲染和科学计算的GPU物理机大数据计算服务MaxCompute：TB/PB级数据仓库解决方案分析型数据库：海量数据实时高并发在线分析开放搜索：结构化数据搜索托管服务管理与监控云监控：指标监控与报警服务访问控制：管理多因素认证、子账号与授权、角色与STS令牌资源编排：批量创建、管理、配置云计算资源操作审计：详细记录控制台和API操作密钥管理服务：安全、易用、低成本的密钥管理服务应用服务日志服务：针对日志收集、存储、查询和分析的服务开放搜索：结构化数据搜索托管服务性能测试：性能云测试平台，帮您轻松完成系统性能评估邮件推送：事务/批量邮件推送，验证码/通知短信服务API网关：高性能、高可用的API托管服务，低成本开放API物联网套件：助您快速搭建稳定可靠的物联网应用消息服务：大规模、高可靠、高并发访问和超强消息堆积能力视频服务视频点播：安全、弹性、高可定制的点播服务媒体转码：为多媒体数据提供的转码计算服务视频直播：低延迟、高并发的音频视频直播服务移动服务移动推送：移动应用通知与消息推送服务短信服务：验证码和短信通知服务，三网合一快速到达HTTPDNS：移动应用域名防劫持和精确调整服务移动安全：为移动应用提供全生命周期安全服务移动数据分析：移动应用数据采集、分析、展示和数据输出服务移动加速：移动应用访问加速云通信短信服务：验证码和短信通知服务，三网合一快速到达语音服务：语音通知和语音验证，支持多方通话流量服务：轻松玩转手机流量，物联卡专供物联终端使用私密专线：号码隔离，保护双方的隐私信息移动推送：移动应用通知与消息推送服务消息服务：大规模、高可靠、高并发访问和超强消息堆积能力邮件推送：事务邮件、通知邮件和批量邮件的快速发送

索引，索引！！！为经常查询的字段建索引！！ 但也不能过多地建索引。insert和delete等改变表记录的操作会导致索引重排，增加数据库负担。优化目标1.减少 IO 次数 IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。2.降低 CPU 计算 除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标优化方法改变 SQL 执行计划 明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标分析复杂的SQL语句explain 例如: mysql> explain select from (select from ( select * from t3 where id=3952602) a) b; id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY system NULL NULL NULL NULL 1 2 DERIVED system NULL NULL NULL NULL 1 3 DERIVED t3 const PRIMARY,idx_t3_id PRIMARY 4 1 很显然这条SQL是从里向外的执行,就是从id=3 向上执行.show show tables或show tables from database_name; // 显示当前数据库中所有表的名称 show databases; // 显示mysql中所有数据库的名称 show columns from table_name from database_name; 或MySQL show columns from database_name.table_name; // 显示表中列名称 show grants for user_name@localhost; // 显示一个用户的权限，显示结果类似于grant 命令 show index from table_name; // 显示表的索引 show status; // 显示一些系统特定资源的信息，例如，正在运行的线程数量 show variables; // 显示系统变量的名称和值show processlist; // 显示系统中正在运行的所有进程，也就是当前正在执行的查询。 show table status; // 显示当前使用或者指定的database中的每个表的信息。信息包括表类型和表的最新更新时间 show privileges; // 显示服务器所支持的不同权限 show create database database_name; // 显示create database 语句是否能够创建指定的数据库 show create table table_name; // 显示create database 语句是否能够创建指定的数据库 show engies; // 显示安装以后可用的存储引擎和默认引擎。 show innodb status; // 显示innoDB存储引擎的状态 show logs; // 显示BDB存储引擎的日志 show warnings; // 显示最后一个执行的语句所产生的错误、警告和通知 show errors; // 只显示最后一个执行语句所产生的错误关于enum 存在争议。 对于取值有限且固定的字段，推荐使用enum而非varchar。但是！！其他数据库可能不支持，导致了难于迁移的问题。开启缓存查询 对于完全相同的sql，使用已经存在的执行计划，从而跳过解析和生成执行计划的过程。 应用场景：有一个不经常变更的表，且服务器收到该表的大量相同查询。对于频繁更新的表，查询缓存是不适合的 Mysql 判断是否命中缓存的办法很简单，首先会将要缓存的结果放在引用表中，然后使用查询语句，数据库名称，客户端协议的版本等因素算出一个hash值，这个hash值与引用表中的结果相关联。如果在执行查询时，根据一些相关的条件算出的hash值能与引用表中的数据相关联，则表示查询命中 查询必须是完全相同的(逐字节相同)才能够被认为是相同的。另外，同样的查询字符串由于其它原因可能认为是不同的。使用不同的数据库、不同的协议版本或者不同 默认字符集的查询被认为是不同的查询并且分别进行缓存。 下面sql查询缓存认为是不同的： SELECT * FROM tbl_name Select * from tbl_name 缓存机制失效的场景 如果查询语句中包含一些不确定因素时（例如包含 函数Current()），该查询不会被缓存,不确定因素主要包含以下情况 · 引用了一些返回值不确定的函数 · 引用自定义函数(UDFs)。 · 引用自定义变量。 · 引用mysql系统数据库中的表。 · 下面方式中的任何一种： SELECT ...IN SHARE MODE SELECT ...FOR UPDATE SELECT ...INTO OUTFILE ... SELECT ...INTO DUMPFILE ... SELECT * FROM ...WHERE autoincrement_col IS NULL · 使用TEMPORARY表。 · 不使用任何表。 · 用户有某个表的列级别权限。额外的消耗 如果使用查询缓存，在进行读写操作时会带来额外的资源消耗，消耗主要体现在以下几个方面 · 查询的时候会检查是否命中缓存，这个消耗相对较小 · 如果没有命中查询缓存，MYSQL会判断该查询是否可以被缓存，而且系统中还没有对应的缓存，则会将其结果写入查询缓存 · 如果一个表被更改了，那么使用那个表的所有缓冲查询将不再有效，并且从缓冲区中移出。这包括那些映射到改变了的表的使用MERGE表的查询。一个表可以被许多类型的语句更改，例如INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE。 对于InnoDB而言，事物的一些特性还会限制查询缓存的使用。当在事物A中修改了B表时，因为在事物提交之前，对B表的修改对其他的事物而言是不可见的。为了保证缓存结果的正确性，InnoDB采取的措施让所有涉及到该B表的查询在事物A提交之前是不可缓存的。如果A事物长时间运行，会严重影响查询缓存的命中率 查询缓存的空间不要设置的太大。 因为查询缓存是靠一个全局锁操作保护的，如果查询缓存配置的内存比较大且里面存放了大量的查询结果，当查询缓存失效的时候，会长时间的持有这个全局锁。因为查询缓存的命中检测操作以及缓存失效检测也都依赖这个全局锁，所以可能会导致系统僵死的情况静态表速度更快定长类型和变长类型 CHAR(M)定义的列的长度为固定的，M取值可以为0～255之间，当保存CHAR值时，在它们的右边填充空格以达到指定的长度。当检索到CHAR值时，尾部的空格被删除掉。在存储或检索过程中不进行大小写转换。CHAR存储定长数据很方便，CHAR字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间,不足的自动用空格填充。 VARCHAR(M)定义的列的长度为可变长字符串，M取值可以为0~65535之间，(VARCHAR的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是65,532字节）。VARCHAR值保存时只保存需要的字符数，另加一个字节来记录长度(如果列声明的长度超过255，则使用两个字节)。VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留，符合标准SQL。varchar存储变长数据，但存储效率没有CHAR高。 如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。VARCHAR和TEXT、BlOB类型 VARCHAR，BLOB和TEXT类型是变长类型，对于其存储需求取决于列值的实际长度(在前面的表格中用L表示)，而不是取决于类型的最大可能尺寸。 BLOB和TEXT类型需要1，2，3或4个字节来记录列值的长度，这取决于类型的最大可能长度。VARCHAR需要定义大小，有65535字节的最大限制；TEXT则不需要。如果你把一个超过列类型最大长度的值赋给一个BLOB或TEXT列，值被截断以适合它。 一个BLOB是一个能保存可变数量的数据的二进制的大对象。4个BLOB类型TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB仅仅在他们能保存值的最大长度方面有所不同。 BLOB 可以储存图片,TEXT不行，TEXT只能储存纯文本文件。 在BLOB和TEXT类型之间的唯一差别是对BLOB值的排序和比较以大小写敏感方式执行，而对TEXT值是大小写不敏感的。换句话说，一个TEXT是一个大小写不敏感的BLOB。 效率来说基本是char>varchar>text，但是如果使用的是Innodb引擎的话，推荐使用varchar代替char char和varchar可以有默认值，text不能指定默认值静态表和动态表 静态表字段长度固定，自动填充，读写速度很快，便于缓存和修复，但比较占硬盘，动态表是字段长度不固定，节省硬盘，但更复杂，容易产生碎片，速度慢，出问题后不容易重建。当只需要一条数据的时候，使用limit 1 表记录中的一行尽量不要超过一个IO单元 区分in和exist select * from 表A where id in (select id from 表B)这句相当于select from 表A where exists(select from 表B where 表B.id=表A.id)对于表A的每一条数据,都执行select * from 表B where 表B.id=表A.id的存在性判断,如果表B中存在表A当前行相同的id,则exists为真,该行显示,否则不显示 区分in和exists主要是造成了驱动顺序的改变（这是性能变化的关键），如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询。 所以IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况复杂多表尽量少用join MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。尽量用join代替子查询 虽然 Join 性能并不佳，但是和 MySQL 的子查询比起来还是有非常大的性能优势。 MySQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句在临时表中查询记录。查询完毕后，MySQL需要插销这些临时表。所以在MySQL中可以使用连接查询来代替子查询。连接查询不需要建立临时表，其速度比子查询要快。尽量少排序 排序操作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。 对于MySQL来说，减少排序有多种办法，比如： 上面误区中提到的通过利用索引来排序的方式进行优化 减少参与排序的记录条数 非必要不对数据进行排序尽量避免select * 大多数关系型数据库都是按照行(row)的方式存储，而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位，一般为4KB，8KB… 大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以，我们是取一个字段还是多个字段，实际上数据库在表中需要访问的数据量其实是一样的。 也有例外情况，那就是我们的这个查询在索引中就可以完成，也就是说当只取 a,b两个字段的时候，不需要回表，而c这个字段不在使用的索引中，需要回表取得其数据。在这样的情况下，二者的IO量会有较大差异。尽量少or 当 where 子句中存在多个条件以“或”并存的时候，MySQL 的优化器并没有很好的解决其执行计划优化问题，再加上 MySQL 特有的 SQL 与 Storage 分层架构方式，造成了其性能比较低下，很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。尽量用 union all 代替 union union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的 CPU 运算，加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用 union all 而不是 union。尽量早过滤 在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。比如我们在多个表进行分页数据查询的时候，我们最好是能够在一个表上先过滤好数据分好页，然后再用分好页的结果集与另外的表 Join，这样可以尽可能多的减少不必要的 IO 操作，大大节省 IO 操作所消耗的时间。避免类型转换 这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换： 人为在column_name 上通过转换函数进行转换直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引，如果非要转换，应该在传入的参数上进行转换，由数据库自己进行转换， 如果我们传入的数据类型和字段类型不一致，同时我们又没有做任何类型转换处理，MySQL 可能会自己对我们的数据进行类型转换操作，也可能不进行处理而交由存储引擎去处理，这样一来，就会出现索引无法使用的情况而造成执行计划问题。优先优化高并发的 SQL，而不是执行频率低某些“大”SQL 对于破坏性来说，高并发的 SQL 总是会比低频率的来得大，因为高并发的 SQL 一旦出现问题，甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量 IO 而且响应很慢的 SQL，由于频率低，即使遇到，最多就是让整个系统响应慢一点，但至少可能撑一会儿，让我们有缓冲的机会。从全局出发优化，而不是片面调整 尤其是在通过调整索引优化 SQL 的执行计划的时候，千万不能顾此失彼，因小失大。尽可能对每一条运行在数据库中的SQL进行 explain 知道 SQL 的执行计划才能判断是否有优化余地，才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后，很明显的问题 SQL 可能已经很少了，大多都需要去发掘，这时候就需要进行大量的 explain 操作收集执行计划，并判断是否需要进行优化。尽量避免where子句中对字段进行null值的判断 会导致引擎放弃索引，进而进行全表扫描。 尽量不要给数据库留null值，尽可能地使用not null填充数据库。可以为每个null型的字段设置一个和null对应的实际内容表述。避免在where中使用!=, >, <操作符 否则引擎放弃使用索引，进行全表扫描。常用查询字段建索引避免在where中使用or imagein和not in关键词慎用，容易导致全表扫面 对连续的数值尽量用between通配符查询也容易导致全表扫描避免在where子句中使用局部变量 sql只有在运行时才解析局部变量。而优化程序必须在编译时访问执行计划，这时并不知道变量值，所以无法作为索引的输入项。 image避免在where子句中对字段进行表达式操作 会导致引擎放弃使用索引 image避免在where子句中对字段进行函数操作 image不要where子句的‘=’左边进行函数、算术运算或其他表达式运算 系统可能无法正确使用索引避免update全部字段 只update需要的字段。频繁调用会引起明显的性能消耗，同时带来大量日志。索引不是越多越好 一个表的索引数最好不要超过6个尽量使用数字型字段而非字符型 因为处理查询和连接时会逐个比较字符串的每个字符，而对于数字型而言只需要比较一次就够了。尽可能用varchar/nvarchar代替char/nchar 变长字段存储空间小，对于查询来说，在一个相对较小的字段内搜索效率更高。。。？避免频繁创建和删除临时表，减少系统表资源消耗select into和create table 新建临时表时，如果一次性插入数据量很大，使用select into代替create table，避免造成大量log，以提高速度。 如果数据量不大，为了缓和系统表的资源，先create table，再insert。 拆分大的DELETE和INSERT语句 因为这两个操作是会锁表的，对于高访问量的站点来说，锁表时间内积累的访问数、数据库连接、打开的文件数等等，可能不仅仅让WEB服务崩溃，还会让整台服务器马上挂了。 所以，一定要拆分，使用LIMIT条件休眠一段时间，批量处理。