[推荐] 大表设计与优化讨论下...贡献全部分,虽然很少~ [问题点数:200分,结帖人xiaoye1202]

Bbs1
本版专家分:32
结帖率 84.62%
Bbs9
本版专家分:52078
版主
Blank
进士 2017年 总版技术专家分年内排行榜第八
Blank
优秀版主 2016年10月优秀大版主
优秀小版主
Blank
银牌 2017年1月 总版技术专家分月排行榜第二
Blank
铜牌 2016年12月 总版技术专家分月排行榜第三
Bbs11
本版专家分:214578
Blank
状元 2014年 总版技术专家分年内排行榜第一
Blank
榜眼 2013年 总版技术专家分年内排行榜第二
Blank
金牌 2014年8月 总版技术专家分月排行榜第一
2014年7月 总版技术专家分月排行榜第一
2014年6月 总版技术专家分月排行榜第一
2014年5月 总版技术专家分月排行榜第一
2014年4月 总版技术专家分月排行榜第一
2014年3月 总版技术专家分月排行榜第一
2014年1月 总版技术专家分月排行榜第一
2013年12月 总版技术专家分月排行榜第一
Blank
优秀版主 2014年11月论坛优秀版主
Bbs8
本版专家分:44191
版主
Blank
金牌 2018年10月 总版技术专家分月排行榜第一
2018年9月 总版技术专家分月排行榜第一
2018年8月 总版技术专家分月排行榜第一
Blank
银牌 2018年11月 总版技术专家分月排行榜第二
2018年7月 总版技术专家分月排行榜第二
Blank
红花 2018年10月 MS-SQL Server大版内专家分月排行榜第一
2018年9月 MS-SQL Server大版内专家分月排行榜第一
2018年8月 MS-SQL Server大版内专家分月排行榜第一
2018年7月 MS-SQL Server大版内专家分月排行榜第一
2018年6月 MS-SQL Server大版内专家分月排行榜第一
2018年3月 MS-SQL Server大版内专家分月排行榜第一
2018年2月 MS-SQL Server大版内专家分月排行榜第一
Blank
黄花 2018年11月 MS-SQL Server大版内专家分月排行榜第二
2018年5月 MS-SQL Server大版内专家分月排行榜第二
2018年4月 MS-SQL Server大版内专家分月排行榜第二
2018年1月 MS-SQL Server大版内专家分月排行榜第二
2017年12月 MS-SQL Server大版内专家分月排行榜第二
2017年11月 MS-SQL Server大版内专家分月排行榜第二
2017年10月 MS-SQL Server大版内专家分月排行榜第二
Bbs7
本版专家分:15901
版主
Blank
黄花 2017年9月 MS-SQL Server大版内专家分月排行榜第二
2017年8月 MS-SQL Server大版内专家分月排行榜第二
2017年7月 MS-SQL Server大版内专家分月排行榜第二
Blank
蓝花 2017年11月 MS-SQL Server大版内专家分月排行榜第三
2017年10月 MS-SQL Server大版内专家分月排行榜第三
Bbs7
本版专家分:15901
版主
Blank
黄花 2017年9月 MS-SQL Server大版内专家分月排行榜第二
2017年8月 MS-SQL Server大版内专家分月排行榜第二
2017年7月 MS-SQL Server大版内专家分月排行榜第二
Blank
蓝花 2017年11月 MS-SQL Server大版内专家分月排行榜第三
2017年10月 MS-SQL Server大版内专家分月排行榜第三
Bbs9
本版专家分:87254
版主
Blank
榜眼 2017年 总版技术专家分年内排行榜第二
Blank
金牌 2018年11月 总版技术专家分月排行榜第一
2017年9月 总版技术专家分月排行榜第一
2017年6月 总版技术专家分月排行榜第一
2017年4月 总版技术专家分月排行榜第一
2017年2月 总版技术专家分月排行榜第一
Blank
银牌 2017年5月 总版技术专家分月排行榜第二
2017年3月 总版技术专家分月排行榜第二
Blank
微软MVP 恭喜获得微软MVP认证
Bbs1
本版专家分:32
Bbs11
本版专家分:214578
Blank
状元 2014年 总版技术专家分年内排行榜第一
Blank
榜眼 2013年 总版技术专家分年内排行榜第二
Blank
金牌 2014年8月 总版技术专家分月排行榜第一
2014年7月 总版技术专家分月排行榜第一
2014年6月 总版技术专家分月排行榜第一
2014年5月 总版技术专家分月排行榜第一
2014年4月 总版技术专家分月排行榜第一
2014年3月 总版技术专家分月排行榜第一
2014年1月 总版技术专家分月排行榜第一
2013年12月 总版技术专家分月排行榜第一
Blank
优秀版主 2014年11月论坛优秀版主
Bbs8
本版专家分:44191
版主
Blank
金牌 2018年10月 总版技术专家分月排行榜第一
2018年9月 总版技术专家分月排行榜第一
2018年8月 总版技术专家分月排行榜第一
Blank
银牌 2018年11月 总版技术专家分月排行榜第二
2018年7月 总版技术专家分月排行榜第二
Blank
红花 2018年10月 MS-SQL Server大版内专家分月排行榜第一
2018年9月 MS-SQL Server大版内专家分月排行榜第一
2018年8月 MS-SQL Server大版内专家分月排行榜第一
2018年7月 MS-SQL Server大版内专家分月排行榜第一
2018年6月 MS-SQL Server大版内专家分月排行榜第一
2018年3月 MS-SQL Server大版内专家分月排行榜第一
2018年2月 MS-SQL Server大版内专家分月排行榜第一
Blank
黄花 2018年11月 MS-SQL Server大版内专家分月排行榜第二
2018年5月 MS-SQL Server大版内专家分月排行榜第二
2018年4月 MS-SQL Server大版内专家分月排行榜第二
2018年1月 MS-SQL Server大版内专家分月排行榜第二
2017年12月 MS-SQL Server大版内专家分月排行榜第二
2017年11月 MS-SQL Server大版内专家分月排行榜第二
2017年10月 MS-SQL Server大版内专家分月排行榜第二
Bbs5
本版专家分:3997
Blank
黄花 2007年8月 VB大版内专家分月排行榜第二
Blank
蓝花 2007年12月 VB大版内专家分月排行榜第三
Bbs14
本版专家分:884921
Blank
名人 年度总版至少三次排名前十即授予名人勋章
Blank
状元 2005年 总版技术专家分年内排行榜第一
2004年 总版技术专家分年内排行榜第一
Blank
进士 2006年 总版技术专家分年内排行榜第六
2003年 总版技术专家分年内排行榜第八
Blank
金牌 2005年6月 总版技术专家分月排行榜第一
2005年5月 总版技术专家分月排行榜第一
2005年4月 总版技术专家分月排行榜第一
2005年3月 总版技术专家分月排行榜第一
2005年2月 总版技术专家分月排行榜第一
2005年1月 总版技术专家分月排行榜第一
2004年12月 总版技术专家分月排行榜第一
2004年11月 总版技术专家分月排行榜第一
2004年10月 总版技术专家分月排行榜第一
2004年9月 总版技术专家分月排行榜第一
2004年8月 总版技术专家分月排行榜第一
2004年7月 总版技术专家分月排行榜第一
2004年6月 总版技术专家分月排行榜第一
2004年5月 总版技术专家分月排行榜第一
2004年4月 总版技术专家分月排行榜第一
2004年3月 总版技术专家分月排行榜第一
2004年1月 总版技术专家分月排行榜第一
2003年12月 总版技术专家分月排行榜第一
Bbs14
本版专家分:884921
Blank
名人 年度总版至少三次排名前十即授予名人勋章
Blank
状元 2005年 总版技术专家分年内排行榜第一
2004年 总版技术专家分年内排行榜第一
Blank
进士 2006年 总版技术专家分年内排行榜第六
2003年 总版技术专家分年内排行榜第八
Blank
金牌 2005年6月 总版技术专家分月排行榜第一
2005年5月 总版技术专家分月排行榜第一
2005年4月 总版技术专家分月排行榜第一
2005年3月 总版技术专家分月排行榜第一
2005年2月 总版技术专家分月排行榜第一
2005年1月 总版技术专家分月排行榜第一
2004年12月 总版技术专家分月排行榜第一
2004年11月 总版技术专家分月排行榜第一
2004年10月 总版技术专家分月排行榜第一
2004年9月 总版技术专家分月排行榜第一
2004年8月 总版技术专家分月排行榜第一
2004年7月 总版技术专家分月排行榜第一
2004年6月 总版技术专家分月排行榜第一
2004年5月 总版技术专家分月排行榜第一
2004年4月 总版技术专家分月排行榜第一
2004年3月 总版技术专家分月排行榜第一
2004年1月 总版技术专家分月排行榜第一
2003年12月 总版技术专家分月排行榜第一
Bbs1
本版专家分:32
Bbs8
本版专家分:44191
版主
Blank
金牌 2018年10月 总版技术专家分月排行榜第一
2018年9月 总版技术专家分月排行榜第一
2018年8月 总版技术专家分月排行榜第一
Blank
银牌 2018年11月 总版技术专家分月排行榜第二
2018年7月 总版技术专家分月排行榜第二
Blank
红花 2018年10月 MS-SQL Server大版内专家分月排行榜第一
2018年9月 MS-SQL Server大版内专家分月排行榜第一
2018年8月 MS-SQL Server大版内专家分月排行榜第一
2018年7月 MS-SQL Server大版内专家分月排行榜第一
2018年6月 MS-SQL Server大版内专家分月排行榜第一
2018年3月 MS-SQL Server大版内专家分月排行榜第一
2018年2月 MS-SQL Server大版内专家分月排行榜第一
Blank
黄花 2018年11月 MS-SQL Server大版内专家分月排行榜第二
2018年5月 MS-SQL Server大版内专家分月排行榜第二
2018年4月 MS-SQL Server大版内专家分月排行榜第二
2018年1月 MS-SQL Server大版内专家分月排行榜第二
2017年12月 MS-SQL Server大版内专家分月排行榜第二
2017年11月 MS-SQL Server大版内专家分月排行榜第二
2017年10月 MS-SQL Server大版内专家分月排行榜第二
Bbs1
本版专家分:65
Bbs11
本版专家分:208645
版主
Blank
银牌 2016年8月 总版技术专家分月排行榜第二
2011年11月 总版技术专家分月排行榜第二
Blank
优秀版主 2016年10月优秀大版主
2016年8月论坛优秀版主
2015年4月优秀版主
2014年11月论坛优秀版主
Blank
微软MVP 2016年4月 荣获微软MVP称号
2015年4月 荣获微软MVP称号
2014年4月 荣获微软MVP称号
2013年4月 荣获微软MVP称号
2009年1月 荣获微软MVP称号
2012年4月 荣获微软MVP称号
2011年4月 荣获微软MVP称号
2010年4月 荣获微软MVP称号
Blank
铜牌 2011年10月 总版技术专家分月排行榜第三
Bbs1
本版专家分:58
Bbs2
本版专家分:313
Bbs14
本版专家分:884921
Blank
名人 年度总版至少三次排名前十即授予名人勋章
Blank
状元 2005年 总版技术专家分年内排行榜第一
2004年 总版技术专家分年内排行榜第一
Blank
进士 2006年 总版技术专家分年内排行榜第六
2003年 总版技术专家分年内排行榜第八
Blank
金牌 2005年6月 总版技术专家分月排行榜第一
2005年5月 总版技术专家分月排行榜第一
2005年4月 总版技术专家分月排行榜第一
2005年3月 总版技术专家分月排行榜第一
2005年2月 总版技术专家分月排行榜第一
2005年1月 总版技术专家分月排行榜第一
2004年12月 总版技术专家分月排行榜第一
2004年11月 总版技术专家分月排行榜第一
2004年10月 总版技术专家分月排行榜第一
2004年9月 总版技术专家分月排行榜第一
2004年8月 总版技术专家分月排行榜第一
2004年7月 总版技术专家分月排行榜第一
2004年6月 总版技术专家分月排行榜第一
2004年5月 总版技术专家分月排行榜第一
2004年4月 总版技术专家分月排行榜第一
2004年3月 总版技术专家分月排行榜第一
2004年1月 总版技术专家分月排行榜第一
2003年12月 总版技术专家分月排行榜第一
Bbs1
本版专家分:30
Bbs1
本版专家分:0
Bbs2
本版专家分:313
Bbs1
本版专家分:0
Bbs1
本版专家分:32
Bbs1
本版专家分:38
Bbs1
本版专家分:0
Bbs14
本版专家分:884921
Blank
名人 年度总版至少三次排名前十即授予名人勋章
Blank
状元 2005年 总版技术专家分年内排行榜第一
2004年 总版技术专家分年内排行榜第一
Blank
进士 2006年 总版技术专家分年内排行榜第六
2003年 总版技术专家分年内排行榜第八
Blank
金牌 2005年6月 总版技术专家分月排行榜第一
2005年5月 总版技术专家分月排行榜第一
2005年4月 总版技术专家分月排行榜第一
2005年3月 总版技术专家分月排行榜第一
2005年2月 总版技术专家分月排行榜第一
2005年1月 总版技术专家分月排行榜第一
2004年12月 总版技术专家分月排行榜第一
2004年11月 总版技术专家分月排行榜第一
2004年10月 总版技术专家分月排行榜第一
2004年9月 总版技术专家分月排行榜第一
2004年8月 总版技术专家分月排行榜第一
2004年7月 总版技术专家分月排行榜第一
2004年6月 总版技术专家分月排行榜第一
2004年5月 总版技术专家分月排行榜第一
2004年4月 总版技术专家分月排行榜第一
2004年3月 总版技术专家分月排行榜第一
2004年1月 总版技术专家分月排行榜第一
2003年12月 总版技术专家分月排行榜第一
Bbs9
本版专家分:97841
Blank
进士 2011年 总版技术专家分年内排行榜第十
Blank
银牌 2011年8月 总版技术专家分月排行榜第二
2011年7月 总版技术专家分月排行榜第二
Blank
微软MVP 2012年7月 荣获微软MVP称号
Blank
红花 2011年8月 MS-SQL Server大版内专家分月排行榜第一
2011年7月 MS-SQL Server大版内专家分月排行榜第一
Bbs1
本版专家分:32
Bbs1
本版专家分:0
Bbs1
本版专家分:32
Bbs1
本版专家分:0
Bbs2
本版专家分:150
Bbs1
本版专家分:0
Bbs1
本版专家分:32
Bbs1
本版专家分:0
其他相关推荐
费马大定理,集惊险与武侠于一体
悬案费马大定理从提出到证明的过程,就是一部不折不扣的惊险小说。一个读者,在自己看过的书空白处留下附注。除了他自己,还有谁会关注呢?但是,法国人费马死后,他在一本《算术》书上所写的注记并没有随之湮没。其长子意识到那些草草的字迹也许有价值,就用五年时间整理,然后印出一个特殊的《算术》版本,载有他父亲所做的边注,那里面包含了一系列的定理。在靠近问题8的页边处,费马写着这么几句话:“不可能将一个立方数写成
MySQL的实战系列:大字段如何优化
MySQL的实战系列:大字段如何优化 背景 – 线上发现一张表,1亿的数据量,物理大小尽然惊人的大,1.2T 最终发现,原来有很多字段,10个VARCHAR,1个文本 这么大的表,会给运维带来很大的痛苦:DDL咋办恢复咋办备份咋办??? 基本知识:InnoDB磁盘格式的InnoDB存储架构 蓝图:数据库 - >表空间 - >页面 - >...
hive两大表关联优化试验
呼叫结果(call_result)与销售历史(sale_history)的join优化: CALL_RESULT: 32亿条/444G SALE_HISTORY:17亿条/439G 原逻辑 Map: 3255 Reduce: 950 Cumulative CPU: 238867.84 sec HDFS Read: 587550313339 HDFS Write: 725372
对人类有重大贡献的年轻人:詹姆斯.沃森(James Watson)
沃森生于1928年4月6日,1953年2月28日,沃森发现震惊世界的DNA双螺旋结构模型,年龄不足25岁,是一个现在的所谓”90后“小毛头。一个小毛头对人类能有什么重大贡献?            发现DNA化学结构是沃森的好运气吗?非也。沃森15岁(1943年)进入美国芝加哥大学学习鸟类(Ornithology),但是,在学习期间,19446年,他阅读了薛定谔《生命是什么?》之后,兴趣发生
[Hive]Hive中表连接的优化,加快查询速度
1、多表连接的执行顺序和MapReduce job优化 select a.ymd ,a.price_close ,b.price_close ,c.price_close from stocks a join stocks b on a.ymd = b.ymd join stocks c on a.ymd = c.ymd where ...
高并发大数据量的数据库的设计优化
一、数据库结构的设计。       数据库模型设计的不合理,不仅会导致客户端和服务端的编程和维护困难,而且会影响到系统实际运行的性能。在系统开始实施之前,完备的数据库模型的设计是必要的。       在一个系统分析设计阶段,由于数据量小,系统负荷低,我们往往只注重功能的实现,而很难注意到性能的薄弱之处。等系统投入运营一段时间后,才发现系统性能在降低,这个时候再去提高性能则往往需要花费更多的人力
MySQL 对于千万级的大表的优化
第一优化你的sql和索引; 第二加缓存,memcached,redis; 第三以上都做了后,还是慢,就做主从复制或主主复制,读写分离,可以在应用层做,效率高,也可以用三方工具,第三方工具推荐360的atlas,其它的要么效率不高,要么没人维护; 第四如果以上都做了还是慢,不要想着去做切分,mysql自带分区表,先试试这个,对你的应用是透明的,无需更改代码,但是sql语
优化设计
1、为什么要进行mysql优化? 假设我们设置一个数据量超过10万条记录的表,来进行我们经常做的查询操作比如:select * from 表名,服务器很慢甚至卡死,需要我们重启数据库服务器,这说明我们的表或者查询SQL是有问题的,所以我们要进行mysql优化 2、数据库优化的目标? 通过各种对数据库的优化方法,获取最高的查询和加载性能,达到查询性能的提高和加载性能的提高。 3、掌握优化的方式和
2017 年哪个公司对开源贡献最多?
在这篇分析报告中,我们将使用 2017 年度截止至当前时间(2017 年 10 月)为止,GitHub 上所有公开的推送事件的数据。对于每个 GitHub 用户,我们将尽可能地猜测其所属的公司。此外,我们仅查看那些今年得到了至少 20 个星标的仓库。以下是我的报告结果。 顶级云服务商的比较 2017 年它们在 GitHub 上的表现: 微软看起来约有 1300
MapReduce的两表join操作优化
注:优化前的分析过程详见本博的上篇博文 案例 地址(Address)和人员(Person)的一对多关联   原始数据 地址(Address)数据 id AddreName 1 beijing 2 shanghai 3 guangzhou 人员(Person)数据 1 zhangsan 1 2 lisi 2 3 wangwu 1 4 zhaoliu 3 5 maqi 3
数据表结构的设计与性能优化
1      数据表结构的设计与性能优化 1.1    、数据表的存储原理 SQL Server每次读取1个存储块,每个存储块大小为8KB,每读取1个存储块计算为1个逻辑读。 问题:如果数据内容非常大,像我们系统中的Feeling字段非常大,就会导致每个存储块存放的数据行数会非常少,这样当我们读取数据时,要读取许多的存储块。   存储块1(8KB)
SQL记录 - MySql大数据导入导出 表优化
select count(1) from exceldatas; #9771551OPTIMIZE table exceldatas;# 修改当前事务的隔离级别为未提交读:read uncommitted# 以查看数据insert导入的进度mysql> set session transaction isolation level read uncommitted;解决mysql 事务未提交...
MySQL优化技术:3范式的表设计
一、数据库分类 关系型数据库 关系型数据库是通过行和列来将数据保存在一张张数据表中,表与表之间存在数据关系。常用的关系型数据库包括:MySQL、Oracle、SQLServer、DB2等 非关系型数据库 以键值对的形式来保存数据,是一种面向对象、面向集合的数据存储方式。常用的非关系型数据库包括:NoSQL、MongoDB等 二、什么是3范式(3NF) 1
[Hive]Hive数据倾斜(大表join大表)
Hive数据倾斜(大表join大表)的现象、思路以及解决方案
数据量10亿级别的数据库表,多行存储成一行、一列扩展成多列之数据优化及迁移方案(一)
问题背景: 原表设计如下,业务上是把登陆用户的商品以priority顺序方式列表显示,但是此列表显示非常慢。 create table t_origin (   user_id     varchar2(11),   goods_id    varchar2(19),   priority    number(2),   update_time DATE      ); comm
hive小表与大表join提升运行效率
问题描述:一小表 1000 row 一大表 60w row 方案一: 在运行的时候发现会自动转为map join 本以为会很快,但是只起了一个map ,join 的计算量 : 单机计算6 亿次,结果一直map 0%  最后运行 1800s  方案二: 采用关闭map join : 但是依旧会很慢 what,why? 因为mapper的数量还是太小了,并行度不够啊。 Laun
一个人赚的钱越多,他对社会的贡献就越大
如果你想知道一个人对国家的贡献有多大,你就看他赚了多少钱,并且现在又在计划怎样来花这些钱!这是五一电子老总向云松原创的经典语录。这是一个很大很深的道理,一般人呢,看不懂,想不明,他一定会举这个例子,那个例子,XXX明星多少钱,XXX贪官多少钱,,,,,,,,我真的懒得跟他争辨。大学生跟一个小学生讨论球是圆的还是方的,这有什么意思呢?能够看懂我这个观点的,一定不是泛泛之辈,一定事业有所成就,
了解MySQL联表查询中的驱动表,优化查询,以小表驱动大表
一、为什么要用小表驱动大表 1、驱动表的定义 当进行多表连接查询时, [驱动表] 的定义为: 1)指定了联接条件时,满足查询条件的记录行数少的表为[驱动表] 2)未指定联接条件时,行数少的表为[驱动表](Important!) 忠告:如果你搞不清楚该让谁做驱动表、谁 join 谁,请让 MySQL 运行时自行判断 既然“未指定联接条件时,行数少的表为[驱动表
现代数据库索引设计优化
计算机与互联网
【多目标优化】Pareto最优解很少
一个随机产生的100BCell群体,其中能有多少是Pareto最优解?我的答案是很少,少到几乎接近0了,偶尔才有一两个,显然我觉得自己在什么地方搞错了。我们说BCell a优于BCell b当且仅当 a在各个目标上都不劣于b,并且至少一个目标上优于b,这是Pareto最优解的定义。于是在一个群体中的非劣解,必须优胜于其他如99个个体,这个概率实在是很小。还是证明100个群体中最多只有一个Paret
数据库表设计优化
一 、数据库表设计原则 1,数据库命名原则:英文字母,多个单词间用下划线’_’,单词尽量简洁、见名知意 2,数据库表命名原则:英文字母,多个单词间用下划线’_’,单词尽量简洁、见名知意 3,数据库表字段类型:尽量用int型,固定长度用char,使用varchar的范围尽量贴合实际,能用tinyint就不要用int和smallint,最好给字段设置默认值,默认值不为null; 4,数据库表字...
人与骆驼
人们第一次看见骆驼时,对这些庞大的动物感到十分惊恐和震惊,都吓得纷纷逃窜. 随着时间的过去,他们渐渐地发现骆驼的脾气顺良,便壮着胆子,勇敢地去靠近它. 过了不久,人们完全明白骆驼这动物根本没脾气,于是便看不起它了,还给它们装上绳套,交给孩子们牵着走.
大量数据表的优化方案
1、对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null最好不要给数据库留NULL,尽可能的使用 NOT NULL填充数据库。 备注、描述、评论之类的可以设置
C# 此错误可能是 CLR 中的 bug,或者是用户代码的不安全部分或不可验证部分中的 bug [问题
1.打开VS-〉调试-〉选项和配置。
Hbase设计以及优化
1、表的设计 1.1、Column Family 由于Hbase是一个面向列族的存储器,调优和存储都是在列族这个层次上进行的,最好使列族成员都有相同的"访问模式(access pattern)"和大小特征。 不要在在一张表里定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。因为某个column family在flush的时候,它邻
MySQL 大表的count()优化
以下是基于我结合B+树的数据结构和对实验结果的推测作出的判断,如有错误,恳请指正!今天实验了一下MySQL的count()操作优化, 以下讨论基于mysql5.7 InnoDB存储引擎. x86 windows操作系统。创建的表的结构如下(数据量为100万): 首先是关于mysql的count(*),count(PK), count(1)哪个快的问题。 实现结果如下: 并没有什么区
oracle索引分类及大表分页查询优化(四)
大数据表分页查询优化:最近在做迁移数据,一个表有150万条数据,分页查询出来,然后多线程结构化数据,插入新表中。跑了14个小时,只迁移了一半左右。一看日志时间都花费在了查询数据上。刚开始执行时,每分钟迁移有8000条左右,到早上过来看,每分钟只有500条左右。         执行比较慢的原sql: select * from (select row_.*, rownum rownum
Mysql 优化之小表驱动大表
-
数据结构的三个方面
数据结构的三个方面
数据库表设计之网站建表优化
在之前遇到过的项目中,常常发现有的人对数据库中的表建的特别的随意,丝毫不考虑使用场景与网站在实际操作中的各种情况 比方说我们现在有一个社交网站要建立一个用户表   叫做db_user 现在这个表里边我们要存放 用户ID,用户名,性别,生日,上次登录时间 及 个人简介 我们举一个常见的反例 很多人都会这样建表有木有,更有甚者建表中除了ID一律varchar(60)   虽然利用上边的...
大表设计思路
大数据量表的设计思路 Renhao 2011/4/7 大数据量表在系统中所占比例极小,但却会成为系统正常运行的性能瓶颈,根据自己对平台的业务了解,提出了个人对大数据量表的基本设计思路,对自己后续的工作也是一个说明参考。 1. 设计原则 大表的设计同系统其他设计一样,也需要遵从以下几个基本原则:  全面性:设计能够支撑与其相关的所有业务和数据承载,而非基于某一个功能点,更多需要从宏
一次成功的sql优化,2个表joinI/O 极大,大约9million
原始sql: 更新#result表,更新warr_bal.I/O大的原因是CIS..trans_acd_bal数据量太大, 并且#result表的数据量并不大,且如果有重复的数据,sum出来的结果呈倍数增长。 CREATE TABLE #scm( scm_no int NULL ,amt money NULL ) INSERT INTO #scm SELECT scm_n
mysql 读写高并发大数据表优化
1.更新频繁尽量使用innode引擎,支持行级锁,降低锁粒度,提高并发量。 2.考虑使用mysql 主从做读写分离,可以利用主库更新,从库进行查询。分担数据库压力,提高并发。 3.考虑使用reids nosql类内存数据库进行读写分离。查询通过先redis查询,无结果再查询mysql,同时将mysql数据库查询存入redis。 4.利用mysql表分区(1-1024),减小表粒度,块式管理数
Google对人类的五大贡献
[转]http://www.solaryf.com/article.asp?id=337与喜欢用“道德”作文章的文科生不同,我对Google的佩服源于Google的功利性杰出贡献。以下排名不分大小。第一大贡献,Google的出现,使得人们的信息获取方式和成本,发生了翻天覆地的变化。举个简单例子,我那天看了个俏皮话,叫被窝放屁,自产自销。我突然想知道,被窝放屁,对人体是否有害?这取决于屁的化学成
left join:多表链接及其语句优化
文章转载自:http://www.cnblogs.com/windamy/articles/585555.html
数据库中经常分组查询的表如何做性能优化(group by)
一、原sql SELECT U.NAME        AS NAME,        U.ACCOUNT,        U.REGION_NAME,        U.ORG_NAME,        L.LOGIN_TIME  AS M   FROM PUB_USER U,        (SELECT t.CREATOR, MAX(t.LOGIN_TIME) LOGIN_TI
大数据表查询优化方案
如果有一张大表,表中的数据有几百万、几千万甚至上亿,要实现实时查询,查询的结果要在十秒钟之内出来,怎么办?如何做优化?本人现在做的项目中,有个表的数据超过3千万行,超过5G的数据。现在需要对表中的数据进行查询统计,之前由于没做优化,导致此表的查询效率非常低下,让使用者非常苦恼,于是本人参与了此表的优化。举个类似的例子,比如表中的结构如下,现在要统计某一天出生的人口数,或者统计某一城市的人口数,或者某
性能优化-单表数据过大
1.项目背景 当数据库单表数据量达到一定程度时,数据查询变得很慢很慢,建立索引已经无法提高查询速度时,该如何对查询速度进行优化呢? 以单表的数据量达到八千万数据, 由于之前的架构设计,数据库设计的原因,直接导致数据库服务器负载过高,cpu 使用率接近百分百, 后端迟迟无法返回数据给前端或返回数据时间高达20-30s,前端不停的请求数据,进一步导致数据库负载增高,差点死亡。
MySQL与PostgreSQL的大表处理性能比较
来自:http://www.oschina.net/question/129318_19029 硬件: Intel E8400 3.0GHz / 4G DDR2 / 1T 7200R HD 操作系统: Windows 7 64bit MySQL: v5.5.8, 64bit, Server模式配置(Windows下的GUI界面配置工具里的选项,所举典型应用场景为将MySQL安装至We
贡献500分或者更多,大家大讨论!!
分布式俺知道什么意思,不过没有做过项目,具体搞不清楚,存储过程什么的也用过,不过还是不怎么清楚什么时候该用,什么时候不该用.rn做过的人,有经验的兄弟们能不能根据自己的经验,来从理论或者程序代码方面,讲解一下?大家讨论一下,怎么样?
SQL优化:表的连接顺序
drop table tab_big; drop table tab_small; create table tab_big  as select * from dba_objects where rownum create table tab_small  as select * from dba_objects where rownum set autotrace traceonly
spark中多表连接优化实例
环境信息: hive1.2.1 spark1.6.1 hadoop2.6.0-cdh5.4.2 memory:1918752, vCores:506表结构: 表名称 表容量 主键 hive存储类型 temp_01_pc_order 5G PC_ORDER_ID RCFile TST_ORDER_RISK 9.4G 非 PC_ORDER_ID RC
Mysql数据库表字段设计优化(状态列)
一、传统用户状态设置    传统的数据库表中,涉及到状态的字段时,通常都会第一反应就是将其设置为0和1来表示。比如需求是,设计一张表来检查用户状态(绑定邮箱,绑定手机,实名认证,是否已经开通VIP),我以前会这样设计Java类。UserInfo@Getter @Setter public class UserInfo extends baseDomain{ private boolean re...
优化Oracle库表设计的若干方法
优化Oracle库表设计的若干方法 优化Oracle库表设计的若干方法
greenplum表级优化建议
虽然GREENPLUM可以降低对优化的要求,但是它也是关系型数据库。所以也需要进行优化。这里主要列出与GP优化的一些建议-PTA(PERFORMANCE TUNNING ADVICE)  PTA RULE No1        在完成大批量数据装载之后,针对目标表总是进行vacuum analyze操作。一方面是如果批处理操作失败,会浪费很多空间,这个操作可以回收这些空间,另一方面,G
查询多表关联时的优化处理
尽量用left join on  而不是select  * from a,b,c where ...left join 而不是Join left join时生成的中间表以左边表为基础,生成数据,此时数据量可以控制。 多个left join后,不要在where里出现表关联的限定条件,此时会破坏掉left规则。 多表时,小表在前,大表在后,字段量少的在前,字段量多的再后,虽然sql编译器
优化算法之正交试验
正交试验设计是研究多因素多水平的又一种设计方法,它是根据正交性从全面试验中挑选出部分有代表性的点进行试验,这些有代表性的点具备“均匀分散,齐整可比”的特点。 日本著名的统计学家田口玄一将正交试验选择的水平组合列成表格,称为正交表。
利用MySQL的表实现树的构建以及优化
利用MySQL的表实现树的构建 数据结构表结构介绍: 程序设计过程中,我们常常用树形结构来表征某些数据的关联关系,如企业上下级部门、栏目结构、商品,省份存储,分类等等,通常而言,这些树状结构需要借助于数据库完成持久化。然而目前的各种基于关系的数据库,都是以二维表的形式记录存储数据信息,因此是不能直接将Tree存入DBMS,设计合适的Schema及其对应的CRUD算法是实现关系型数据库中
SQL优化:从设计表结构开始(层次型表结构设计方法)
在业务中,经常会涉及到 数据本身是自关联的情况,比如,组织架构数据,每个人都会有一个上级,那么就是 id,parent_id 这样的设计。 但是这么设计之后,如果我要查询某个人的所有下级,就要用递归查询来遍历,一个是查询sql比较复杂,另一个是对于数据量稍大点的,性能肯定不会好到那里去。 那要怎么设计层次型表的结构呢? 一个比较好的方法就是在表中增加一个字段 cover_code,数
如何设计一张千万级别的大表
1、数据的容量:1-3年内会大概多少条数据,每条数据大概多少字节;  2、数据项:是否有大字段,那些字段的值是否经常被更新;  3、数据查询SQL条件:哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等;  4、数据更新类SQL条件:有多少列经常出现UPDATE或DELETE 的WHERE子句中;  5、SQL量的统计比,如:SELECT:UPDATE+DE
数据库mysql表设计的三大规范
2018年5月22日a  所有字段值都是不可分解的原子值b  也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中c   数据表中的每一列数据都和主键直接相关,而不能间接相关1.第一范式(确保每列保持原子性)第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。第一范式的合理遵循需要根据系统的实际需求来定。比如...
基本上最全的 MySQL 大表优化方案了
当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT...
关于Sql Servel 表数据量大的优化处理。
这几天遇到业务表由于数据量过大导致整体的业务操作都很慢,而且又没有帐套机制,导致转数据很麻烦,还要修改程序。    所以我自己想到一个简单方法,程序设计的时候查询用视图,视图里放着主业务表和历年的帐套表。视图里我们可以很快的修改查询的内容。   比如有个业务表叫A表,还有个2016年的帐套表,A_2015。主业务还是可以继续使用A表做操作,但是2015年的数据全部转到A_2015里。做一个视图
表的数据量特别大时是怎么处理的
1、索引优化和SQL语句优化是必须的,避免模糊查询和非索引查询,删改操作根据聚集索引进行,删改操作太频繁的话还是需要考虑分表2、看需求,如果需求不限制,那就分表分区会增加管理复杂度和成本这个很难理解,分区增加不了多少工作,如果需求要求必须单表,分区是解决在千万到几亿数据量的比较合适的方法可能更大数据量还是要回到分的路上,但是可能更多考虑分布式3、我们一般都是把历史数据定期转存其他表(一样的表名后加年
oracle表设计
oltp: 1按常访问的列(主键等),顺序排列,把允许null的字段放后面 2一个维度一个表,数据值最好是1:1或1:n的关系 3注释的习惯,和索引列表 4表数据和索引数据放不同的表空间 5powerdesigner工具使用 6主键如果使用序列导致热块,可以使用反键索引(反向键索引也有它局限性:如果在WHERE语句中,需要对索引列的值进行范围性的搜索,如BETWEEN、等,其反向键索引
【Mysql性能优化四】数据表的设计和读写分离技术
mysql优化可以从子查询,数据类型和索引等多个方面进行优化。这些都是从sql语句的方向进行考虑的。当我们的sql语句没有优化的空间的时候, 我们就必须从其他方面来考虑进行数据库性能优化了。 数据表设计范式化和反范式化范式化是指我们在设计表时要遵循数据库设计的三个范式,通常要符合第三范式:表中的列之间不能存在传递依赖。 但这并不是一定的。为了查询效率考虑,把原本符合范式化的表设计适当增加冗余,以空间
left join的优化,小的结果集驱动大的结果集
left join 的时间开销类似于笛卡尔积,相当费时,如果关联字段是索引字段,可以减少时间复杂度,但是还是非常费时。 left 的优化:首先,mysql都是使用(Nested Loop )循环套嵌的方式实现join,这里包括两个部分:驱动表结果集作为条件连接被驱动表X,被驱动表根据驱动表结果查询数据集Y。时间复杂度(X*Y),这里的第二部分是数据库内部的操作,涉及io,cpu等的操作很少,而且...
MySQL 对于千万级的大表要怎么优化? - MySQL - 知乎
很多人第一反应是各种切分;我给的顺序是: 第一优化你的sql和索引; 第二加缓存,memcached,redis; 第三以上都做了后,还是慢,就做主从复制或主主复制,读写分离,可以在应用层做,效率高,也可以用三方工具,第三方工具推荐360的atlas,其它的要么效率不高,要么没人维护; 第四如果以上都做了还是慢,不要想着去做切分,mysql自带分区表,先试试这个,对你的应用是透
对于一张表的数据很大时查询数据的优化
根据条件查询一张很大表的数据:比如,根据  对账日期, 渠道编号和全部的交易类型查询数据查询数据t_cbs_recon_bank_order_cps这张表的数据量很大     交易类型:有 像: 消费  退货  线下退货  快退 托收等   正常的思路: 将交易类型封装成一个List,然后作为参数传进去, 这样整个表查询的话, 会很慢。   解决: 类似于分区的的思想, 将不同交易类型的数据
设计三大范式
第一范式(1NF)无重复的列 第二范式(2NF)属性完全依赖于主键 第三范式(3NF)属性不依赖于其它非主属性 第一范式:确保每列的原子性. 如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式. 例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。第二范式:在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关. 如果...
mysql数据库优化--(2)设计 字段类型的选择
建表时,往往需要考虑字段的类型的问题. 可优化性不强,需要注意以下的几个原则 2.1       尽可能占用更少的存储空间 多少字节Byte! tinyint:1, smallint 2, mediumint 3, int 4, bigint 8 但是小空间带来的问题,存储量的减少,范围的减少. Boolean =tinyint     datetime:8 timestam
《数据库索引设计优化》读书笔记(五)
第8章 为表连接设计索引 练习 8.1 评估图8.25中所示连接的响应时间,过滤因子使用给定的值。 分析: A为父表,B为子表,两个表做主外键关联查询,只有主键和外键上有索引,并且A表的主键索引和B表的外键索引为聚簇索引。 以A作为外层表做嵌套循环连接计算响应时间: 第1步:通过聚簇索引AK访问A表 索引 AK TR = 1 TS = 10000000 LTR 1
哲学是否有意义?哲学家对社会的贡献在哪里?
徐向东在谈到哲学的任务时说过:作为一种反思性的活动,哲学必须超越任何既存的意识形态,为设想更加值得向往的人类生活提供一个基础。
大数据量查询优化——数据库设计、SQL语句、JAVA编码
数据库设计方面: 1、对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描。              如: select id from t where num is null               可以在num上设
我们是很有底线的