189 8069 5689
几面：
10年积累的网站设计、成都网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先建设网站后付款的网站建设流程，更有黄石免费网站建设让你可以放心的选择与我们合作。
硬件软件及语言
硬件抗住
软件mysql没设置数据库设计面等
语言SQL语句写
面些优化技巧
1.查询进行优化应尽量避免全表扫描首先应考虑 where 及 order by 涉及列建立索引
2.应尽量避免 where 句字段进行 null 值判断否则导致引擎放弃使用索引进行全表扫描：select id from t where num is nullnum设置默认值0确保表num列没null值查询：select id from t where num=0
3.应尽量避免 where 句使用!=或操作符否则引擎放弃使用索引进行全表扫描
4.应尽量避免 where 句使用or 连接条件否则导致引擎放弃使用索引进行全表扫描：select id from t where num=10 or num=20查询：select id from t where num=10 union all select id from t where num=20
5.in not in 要慎用否则导致全表扫描：select id from t where num in(1,2,3) 于连续数值能用 between 要用 in ：select id from t where num between 1 and 3
6.面查询导致全表扫描：select id from t where name like '李%'若要提高效率考虑全文检索
7.
where
句使用参数导致全表扫描SQL运行才解析局部变量优化程序能访问计划选择推迟运行；必须编译进行选择
编译建立访问计划变量值未知作索引选择输入项面语句进行全表扫描：select id from t where num=@num改强制查询使用索引：select id from t with(index(索引名)) where num=@num
8.应尽量避免 where 句字段进行表达式操作导致引擎放弃使用索引进行全表扫描：select id from t where num/2=100应改:select id from t where num=100*2
9.应尽量避免where句字段进行函数操作导致引擎放弃使用索引进行全表扫描：select id from t where substring(name,1,3)='abc' nameabcid
应改:
select id from t where name like 'abc%'
10.要 where 句=左边进行函数、算术运算或其表达式运算否则系统能确使用索引
11.使用索引字段作条件该索引复合索引必须使用该索引第字段作条件才能保证系统使用该索引否则该索引使用并且应尽能让字段顺序与索引顺序相致
12.要写些没意义查询需要空表结构：select col1,col2 into #t from t where 1=0
类代码返任何结集消耗系统资源应改：
create table #t(...)
13.候用 exists 代替 in 选择：select num from a where num in(select num from b)
用面语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并所索引查询都效SQL根据表数据进行查询优化索引列量数据重复SQL查询能利用索引表字段sexmale、female几乎各半即使sex建索引查询效率起作用
15.
索引并越越索引固 提高相应 select 效率同降低 insert 及 update 效率 insert
或 update
能重建索引所建索引需要慎重考虑视具体情况定表索引数要超6若太则应考虑些使用列建索引否
必要
16.
应尽能避免更新 clustered 索引数据列 clustered
索引数据列顺序表记录物理存储顺序旦该列值改变导致整表记录顺序调整耗费相资源若应用系统需要频繁更新
clustered 索引数据列需要考虑否应该索引建 clustered 索引
17.尽量使用数字型字段若含数值信息字段尽量要设计字符型降低查询连接性能并增加存储销引擎处理查询连接逐比较字符串每字符于数字型言需要比较够
18.尽能使用 varchar/nvarchar 代替 char/nchar 首先变字段存储空间节省存储空间其于查询说相较字段内搜索效率显要高些
19.任何都要使用 select * from t 用具体字段列表代替*要返用任何字段
20.尽量使用表变量代替临表表变量包含量数据请注意索引非限（主键索引）
21.避免频繁创建删除临表减少系统表资源消耗
22.临表并使用适使用使某些例程更效例需要重复引用型表或用表某数据集于性事件使用导表
23.新建临表性插入数据量使用 select into 代替 create table避免造量 log 提高速度；数据量缓系统表资源应先create tableinsert
24.使用临表存储程务必所临表显式删除先 truncate table drop table 避免系统表较间锁定
25.尽量避免使用游标游标效率较差游标操作数据超1万行应该考虑改写
26.使用基于游标或临表前应先寻找基于集解决案解决问题基于集通更效
27.
与临表游标并使 用型数据集使用 FAST_FORWARD
游标通要优于其逐行处理尤其必须引用几表才能获所需数据结集包括合计例程通要比使用游标执行速度快发
间允许基于游标基于集都尝试看哪种效更
28.所存储程触发器始处设置 SET NOCOUNT ON 结束设置 SET NOCOUNT OFF 需执行存储程触发器每语句向客户端发送DONE_IN_PROC 消息
29.尽量避免事务操作提高系统并发能力
30.尽量避免向客户端返数据量若数据量应该考虑相应需求否合理
8 PSR 1LS error 1LS 输入顺序错误电梯停底层 DZ 作没 1LS 信号或者 1LS 信号 1LS 关前作能
show full processlist; -- 查询全部当前进程;
show processlist;-- 只列出前100条
kill 99; -- 99为卡死id
show status;
mysql千万数据加索引卡死关键字？
想到了从以下方法进行解决：
1）重写Sql，让查询命中索引
2）增加索引
3）1）或者2）方法之后，再加上一个缓存功能
最快捷的方式肯定是2了，但是本表由于逻辑复杂，时不时又批量录入一些数据，已经有了5个索引了，再加索引，恐怕会导致写入慢的问题，而且加索引可能会引起锁表问题。
于是，我先想用方法1解决，可是由于逻辑有点复杂，查询语句比较复杂，改了很多写法都不理想，最后还是选择了方法2，直接表加索引。
由于对于加索引的一些担忧，于是我在本地先尝试了一下（本地数据和线上数据量基本一致，相差不大），结果没想到还挺快的，对于写入的性能也没多大的影响。加入索引后页面秒开，效果很好。
问题
我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办?
实验
我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。
写个简单的脚本，制造一批带主键和不带主键的表：
执行一下脚本：
现在执行以下 SQL 看看效果：
...
执行了 16.80s，感觉是非常慢了。
现在用一下 DBA 三板斧，看看执行计划：
感觉有点惨，由于 information_schema.columns 是元数据表，没有必要的统计信息。
那我们来 show warnings 看看 MySQL 改写后的 SQL：
我们格式化一下 SQL：
可以看到 MySQL 将
select from A where A.x not in (select x from B) //非关联子查询
转换成了
select from A where not exists (select 1 from B where B.x = a.x) //关联子查询
如果我们自己是 MySQL，在执行非关联子查询时，可以使用很简单的策略：
select from A where A.x not in (select x from B where ...) //非关联子查询:1. 扫描 B 表中的所有记录，找到满足条件的记录，存放在临时表 C 中，建好索引2. 扫描 A 表中的记录，与临时表 C 中的记录进行比对，直接在索引里比对，
而关联子查询就需要循环迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //关联子查询扫描 A 表的每一条记录 rA： 扫描 B 表，找到其中的第一条满足 rA 条件的记录。
显然，关联子查询的扫描成本会高于非关联子查询。
我们希望 MySQL 能先"缓存"子查询的结果（缓存这一步叫物化，MATERIALIZATION），但MySQL 认为不缓存更快，我们就需要给予 MySQL 一定指导。
...
可以看到执行时间变成了 0.67s。
整理
我们诊断的关键点如下：
\1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息。
\2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。
\3. 我们增加了 hint，指导 MySQL 正确进行优化判断。
但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。