数据库优化

分库、分表、表分区 来源场景：读写分离以后可分为一个主库 ( 主库负责写 ) 加上 N 多个从库 ( 从库负责读 ) ， 但是因为业务量的扩大，主库还是无法承受写入的压力，那么此时就可以考虑分库、分表、表分区 来进一步优化 分库： 场景 1 ：比如一个系统涵盖了订单 \ 物流 \ 仓储 ..... 等等 垂直分库，按业务拆分库，不同库不同的服务器 场景 2：订单增删改特别大 水平分库，每个库结构一致数据不一致 (地域/时间/类别/随机算法) 分表 场景 1 ： 文章表， 10个常规字段+1个很长的内容字段 垂直分表，减小表体积，提升增删改查的效率 场景 2： 单表数据量太大 (订单表/商品表) 水平分表 (地域/时间/类别/随机算法) 表分区 一般情况下，我们建立数据库表时，表数据都存放在一个文件里。 但是如果是分区表的话，表数据就会按照你指定的规则分放到不同的文件里，把一个大的数据文件拆分为多个小文件，还可以把这些小文件放在不同的磁盘下由多个 cpu进行处理。这样文件的大小随着拆分而减小，还得到硬件系统的加强，自然对我们操作数据是大大有利的。 所以大数据量的数据表，对分区的需要还是必要的，因为它可以提高 select效率，还可以对历史数据经行区分存档等。但是数据量少的数据就不要凑这个热闹啦，因为表分区会对数据库产生不必要的开销，除啦性能还会增加实现对象的管理费用和复杂性。

目录 orm相关的数据库查询优化 惰性查询 all、only与defer select_related与prefetch_related MTV与MVC模型 MTV(models templates views) MCV(models views controllar) choices参数 Ajax（重要） AJAX简介 AJAX的应用场景 AJAX前的知识储备 ajax基本语法结构： 前后端传输数据的编码格式 AJAX如何传输json数据 orm相关的数据库查询优化 惰性查询 惰性查询指当我们只查数据库而不是用这些数据时，Django不会执行查询数据库的代码，目的是减少不必要的数据库操作，降低数据库的压力。 如： res = models.Book.objects.all()#只有当我们使用res时才会执行数据库查询的操作 all、only与defer all 拿到自己的所有的属性，但是没有与其他表建立外键的属性。 only only括号内放字段，查询结果是一个列表套一个个数据对象，这些数据对象点括号内的字段属性，不会再查数据库，直接就是对象获取属性；也支持点其他属性，但是其他属性会每拿一条数据就走一次数据库。 res = models.Book.objects.only('name')#查询一次 print(res) for i in res: print(i.name)

原文： SqlServer性能检测和优化工具使用详细 工具概要 如果你的数据库应用系统中，存在有大量表，视图，索引，触发器，函数，存储过程，sql语句等等，又性能低下，而苦逼的你又要对其优化，那么你该怎么办？哥教你，首先你要知道问题出在哪里？如果想知道问题出在哪里，并且找到他，咱们可以借助本文中要讲述的性能检测工具--sql server profiler（处在sql安装文件--性能工具--sql server profiler） 如果知道啦问题出现在哪里，如果你又是绝世高手，当然可以直中要害，写段代码给处理解决掉，但是如果你不行，你做不到，那么也无所谓，可以借助哥的力量给你解决问题。哥给你的武功的秘诀心法是---数据库引擎优化顾问（处在sql安装文件--性能工具--数据库引擎优化顾问） sql server profiler功能 此工具比柯南还柯南，因为他能检测到数据库中的一举一动，即便你不动他，他也在监视你，他很贱的。他不但监视，还监视的很详细，有多详细一会再说，还把监视的内容记录到数据库或者是文件中，给你媳妇告状说你把数据库哪里的性能搞的多么不好，不过他也会把好的给你记录下来，好与不好这当然需要你来分析，其实他也是个很2的柯南。 数据库引擎优化顾问功能 此武功，乃上乘武功。像张无忌的乾坤大挪移，先是接受sql server profiler检测出来的sql，视图，存储过程

开启查询缓存，优化查询。 explain 你的 select 查询，这可以帮你分析你的查询语句或是表结构的性能瓶颈。 EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的。 当只要一行数据时使用 limit 1 ， MySQL 数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据。 为搜索字段建索引。 使用 ENUM 而不是 VARCHAR 。如果你有一个字段，比如“性别”、“状态”或“部门”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。 Prepared Statements ，预编译语句 Prepared Statements 很像存储过程，是一种运行在后台的 SQL 语句集合，我们可以从使用 prepared statements 获得很多好处，无论是性能问题还是安全问题。 Prepared Statements 可以检查一些你绑定好的变量，这样可以保护你的程序不会受到“ SQL 注入式”攻击。 垂直分表； 根据业务需求，选择合适的存储引擎。 转自： https://xushanxiang.com/2019/11/mysql-optimization-tips.html 来源： https://www.cnblogs.com/xusx2014/p/11904840

一：优化说明 A：有数据表明，用户可以承受的最大等待时间为8秒。数据库优化策略有很多，设计初期，建立好的数据结构对于后期性能优化至关重要。因为数据库结构是系统的基石，基础打不好，使用各种优化策略，也不能达到很完美的效果。 B：数据库优化的几个方面 ​​ 可以看出来，数据结构、SQL、索引是成本最低，且效果最好的优化手段。 C：性能优化是无止境的，当性能可以满足需求时即可，不要过度优化。 二：优化方向 1. SQL以及索引的优化 首先要根据需求写出结构良好的SQL，然后根据SQL在表中建立有效的索引。但是如果索引太多，不但会影响写入的效率，对查询也有一定的影响。 2. 合理的数据库是设计 根据数据库三范式来进行表结构的设计。设计表结构时，就需要考虑如何设计才能更有效的查询。 数据库三范式： 第一范式：数据表中每个字段都必须是不可拆分的最小单元，也就是确保每一列的原子性； 第二范式：满足一范式后，表中每一列必须有唯一性，都必须依赖于主键； 第三范式：满足二范式后，表中的每一列只与主键直接相关而不是间接相关(外键也是直接相关)，字段没有冗余。 注意：没有最好的设计，只有最合适的设计，所以不要过分注重理论。三范式可以作为一个基本依据，不要生搬硬套。 有时候可以根据场景合理地反规范化： A：分割表。 B：保留冗余字段。当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的字段

优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。 降低 CPU 计算 除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户（这些操作基本上都是 CPU 处理内存中的数据比较运算）。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标 优化方法 改变 SQL 执行计划 明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标 常见误区 count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对 count(*)

一、数据库设计优化 1、不要使用游标。 使用游标不仅占用内存，而且还用不可思议的方式锁定表，它们可以使DBA所能做的一切性能优化等于没做。游标里每执行一次fetch就等于执行一次select。 2、创建适当的索引 每当为一个表添加一个索引，select会更快，可insert和delete却大大变慢，因为创建了维护索引需要许多额外的工作。 （1）采用函数处理的字段不能利用索引 （2）条件内包括了多个本表的字段运算时不能进行索引 3、使用事务 对于一些耗时的操作，使用事务可以达到很好的优化效果。 4、小心死锁 按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。 如果某个存储过程先锁定表B，再锁定表A，这可能会导致一个死锁。 5、不要打开大的数据集 6、不要使用服务器端游标 与服务器端游标比起来，客户端游标可以减少服务器和网络的系统开销，并且还减少锁定时间。 7、不要忽略同时修改同一记录的问题 有时候，两个用户会同时修改同一记录，这样，后一个修改者修改了前一个修改者的操作，某些更新就会丢失。处理这种情况，创建一个timestamp字段，在写入前检查它，如果允许，就合并修改，如果存在冲突，提示用户。 8、尽量不要使用text数据类型 除非使用text处理一个很大的数据，否则不要使用它。因为它不易于查询，速度慢

背景 “那啥，你过来一下！” “怎么了？我代码都单元测试了的，没出问题啊！”我一脸懵逼跑到运维大佬旁边。 “你看看！你看看！多少条报警，赶快优化一下！” 运维大佬短信列表里面好多MySQL CPU 100%报警短信。再看看项目名称不就是我前几天刚发布的项目吗！？ 我心底一沉，赶快赔上笑脸。“这个一定优化，马上优化！那个，能不能看下数据库监控日志…” 运维大佬又数落了我几句，然后调开了数据库监控日志。 那家伙…每秒300多的连接数，几乎快要封顶的全表扫描数，还有大红色CPU警报。。。 “那个，能不能看看nginx访问日志…我看下访问量…”我弱弱地说到。 运维大佬不情愿的跑了下下面的语句： grep -c come access.log Shell come这个接口是其中一个请求量比较大的接口，结果是600多万。那个时候才中午，周末高峰期估计一天得有上千万吧！ 我撇了撇嘴，心里想着这么高的请求量，当初那么抠门只给我一台低配数据库还好意思说，不过嘴上肯定是：“好好好，请求量不是很大，看来是数据库问题，我立刻去优化一下！” “给它弄一个读写分离不就行了吗！？”这时另外一个运维大佬凑了过来，随意地挥了挥手。。。 你问我DBA去哪儿了？DBA当时有点忙，只说让我自己检查一下。。。 优化思路 我这个项目由于上线之前比较赶，所以前期并没有管数据库设计方面的一些问题，如今随着游戏接入

1. Oracle跟SQL Server 2005的区别？ 宏观上： 1). 最大的区别在于平台，oracle可以运行在不同的平台上，sql server只能运行在windows平台上，由于windows平台的稳定性和安全性影响了sql server的稳定性和安全性 2). oracle使用的脚本语言为PL-SQL，而sql server使用的脚本为T-SQL 微观上： 从数据类型, 数据库 的结构等等回答 2. 如何使用Oracle的游标？ 1). oracle中的游标分为显示游标和隐式游标 2). 显示游标是用cursor...is命令定义的游标，它可以对查询语句(select)返回的多条记录进行处理；隐式游标是在执行插入 (insert)、删除(delete)、修改(update)和返回单条记录的查询(select)语句时由PL/SQL自动定义的。 3). 显式游标的操作：打开游标、操作游标、关闭游标；PL/SQL隐式地打开SQL游标，并在它内部处理SQL语句，然后关闭它 3. Oracle中function和procedure的区别？ 1). 可以理解函数是存储过程的一种 2). 函数可以没有参数,但是一定需要一个返回值，存储过程可以没有参数,不需要返回值 3). 函数return返回值没有返回参数模式，存储过程通过out参数返回值, 如果需要返回多个参数则建议使用存储过程

转自： https://www.cnblogs.com/rjzheng/p/9619855.html#4365629 引言 大家在面试的时候，是否遭遇过，面试官询问 你们是如何进行数据库优化的? 那这个问题应该怎么答呢？其实写这个题材的原因是我这几天看到各公众号转的一篇数据库调优的知识（不上链接了），我就稍微翻了几下，上面动不动就来说要对数据库进行 水平拆分 ，我就想反问各位读者，你们几个人经历过 水平拆分 ?现在很多文章，实践性实在太差，只能说纯理论分析。 这篇文章最早来自知乎的一个提问，我在其基础上完善了一下。 第一阶段 优化sql和索引 这才是调优的第一阶段啊， 为什么呢？ 因为这一步成本最低啊，不需要加什么中间件。你没经过索引优化和SQL优化，就来什么 水平拆分 ，这不是坑人么。 那 步骤 是什么样呢?我说个大概 (1)用慢查询日志定位执行效率低的 SQL 语句，开启慢查询日志方式： (2)用 explain 分析 SQL 的执行计划 (3)确定问题，采取相应的优化措施，建立索引啊，等 我就不举例了，因为如何优化SQL的文章，一抓一大把，再贴过来，读者看着也累。 第二阶段 搭建缓存 在优化sql无法解决问题的情况下，才考虑搭建缓存。毕竟你使用缓存的目的，就是将复杂的、耗时的、不常变的执行结果缓存起来，降低数据库的资源消耗。 这里需要 注意 的是:搭建缓存后