关于Schema设计规范及SQL使用建议

【关于Schema设计规范及SQL使用建议】的更多相关文章

关于Schema设计规范及SQL使用建议

1.所有的InnoDB表都设计一个无业务用途的自增列做主键,对于绝大多数场景都是如此,真正纯只读用InnoDB表的并不多,真如此的话还不如用TokuDB来得划算: 2.字段长度满足需求前提下,尽可能选择长度小的.此外,字段属性尽量都加上NOT NULL约束,可一定程度提高性能: 3.尽可能不使用TEXT/BLOB类型,确实需要的话,建议拆分到子表中,不要和主表放在一起,避免SELECT * 的时候读性能太差. 4.读取数据时,只选取所需要的列,不要每次都SELECT *,避免产生严重的随机读问题…

OCM_第十四天课程：Section6 —》数据库性能调优_各类索引 /调优工具使用/SQL 优化建议

注:本文为原著(其内容来自腾科教育培训课堂).阅读本文注意事项如下: 1:所有文章的转载请标注本文出处. 2:本文非本人不得用于商业用途.违者将承当相应法律责任. 3:该系列文章目录列表: 一:<OCM 基本班课程表> 二:<OCM_第一天课程:OCM课程环境搭建> 三:<OCM_第二天课程:Section1 ->配置 Oracle 网络环境 > 四:<OCM_第三天课程:Section1 ->表空间的操作和管理.服务配置 > 五:<OC…

MySql设计规范及SQL索引优化【呕心之作】

数据库及表结构基本设计规范 1. 所有表必须使用Innodb存储引擎没有特殊要求(即Innodb无法满足的功能如:列存储,存储空间数据等)的情况下,所有表必须使用Innodb存储引擎(mysql5.5之前默认使用Myisam,5.6以后默认的为Innodb).Innodb 支持事务,支持行级锁,更好的恢复性,高并发下性能更好. 2. 优先选择符合存储需要的最小的数据类型列的字段越大,建立索引时所需要的空间也就越大,索引的性能也越差. 3. 尽可能把所有列定义为NOT NULL 索引NULL列…

sql优化建议

背景: 在北京工作期间,我们做应用开发的和后台数据库的联系非常大,我们经常在一起讨论存储过程或者是sql性能优化的事情来降低应用运行时的时间,提高性能,经过和数据库方面的工程师的一些讨论与学习,收获了一些对优化sql比较有帮助的几点建议,同时在应用开发的实践中,证实的确可以相当可观的提高查询效率,特分享一下. 介绍: 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where及 order by涉及的列上建立索引. 2.应尽量避免在 where子句中使用!=或<>操作符,否…

【 PostgreSQL】十条实用数据库SQL优化建议

基于PostgreSQL,总结几条常用的查询操作的优化建议,部分也适用于Oracle等数据库. 1.选择合适的分布键分布键选择不当会导致重分布.数据分布不均等,而数据分布不均会使SQL集中在一个segment节点的执行,限制了gp整体的速度.查看某表是否分布不均: select gp_segment_id,count(*) from table_name group by gp_segment_id ; 例子如图: 2.使用分区表按照某字段进行分区,不影响数据在数据节点上的分布,但是,仅在单…

写给新员工的十点SQL开发建议

1.建立自己的知识体系摘抄一句话你所拥有的知识并不取决于你记得多少,而在于它们能否在恰当的时候被回忆起来: 做笔记: 把笔记放在可以随时被找到的地方.个人的笔记可以放在印象笔记之类工具上,单位上的笔记,本地保存一份后,建议同步到码云少数核心的内容要被熟练记忆,数据仓库常见表,常见表的常见字段,常见表的关联条件: 2.知己知彼 2.1.使用前查看数据,做数据探索 use db go --查看一下内容: select top 10 * from XXXXX select * from XXXXX…

sql 优化建议

1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 最好不要给数据库留NULL,尽可能的使用 NOT NULL填充数据库. 备注.描述.评论之类的可以设置为 NULL,其他的,最好不要使用NULL. 不要以为 NULL 不需要空间,比如:char(100) …