暂无图片
暂无图片
暂无图片
SQL优化案例
2023-09-18 20:01:45 2091
简介:各种数据库下SQL优化案例
MySQL下的加密解密函数AES_DECRYPT
droptabletpasswd;mysqlCREATETABLEtpasswd(pass1blob,pass2blob,pass3blob);mysqlINSER
姚崇
2023-10-03
272 浏览
MySQL date/timestamp类型和空串union all行为
MySQLdate/timestamp类型unionall转换为char类型mysqlcreatetablecurrselectcurrentdatefromdual;Quer
姚崇
2023-10-03
131 浏览
MySQL中group_concat中order by语句拿出来
原SQL如下:selectt.,tb.summary,tb.businflagname,tb.subaccoinfo,tb.
姚崇
2023-10-03
601 浏览
MySQL中的update left join
原SQLMySQL中updateleftjoin测试语句droptableaa;droptableb;createtableaa(idint,namevarchar(100)
姚崇
2023-10-03
465 浏览
感受greenplum下semi join和inner join性能差异
greenplum下的慢SQLSQL如下:SELECTInnerCode,PersonalCode,AccessionDate,RANKASTypeRank,SLASTypeNumb
姚崇
2023-09-18
222 浏览
SQL Server关于AlwaysOn的理解-读写分离的误区(一)
很多人认为AlwaysOn在同步提交模式下数据是实时同步的,也就是说在主副本写入数据后可以在辅助副本立即查询到。因此期望实现一个彻底的读写分离策略,即所有的写语句在主副本上,所有的只读语句分离到辅助副本上。这是一个认知误区,本文通过原理和测试进行解释。从下图可以看到,在同步提交模式下,主副本产生的日志被同步并固化到辅助副本的日志文件后,主副本的事务就会提交。要强调的是,这种实现原理是为了对主副本上的写入操作的性能影响最小化,并不会导致数据丢失。因此不会丢失数据,只是稍微增加了一点故障转移的时间。创建一个AlwaysOn可用性组,2个同步提交的副本,Node1为主副本,Node2为辅助副本。北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业,成立于2008年,创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴。
z_cloud_for_SQL
2023-09-15
331 浏览
记录一次费脑细胞的planning time 时间长的问题
SQL如下explainanalyzeSELECTFROM(SELECT(CASEWHENE.cbusinflag'137'THENE.vctrade
姚崇
2023-07-20
69 浏览
暂无图片
近期活动
奇点时刻・数智跃迁——云和恩墨2025春季产品发布会
03/31 15:00 0人报名
【开始报名啦】4月12日 TiDB社区活动在南京!传统技术栈替换和 AI 浪潮正当时,面向未来的国产数据库怎么选择?
04/12 14:00 0人报名
Apache Cloudberry™ (Incubating) Meetup · 杭州
04/19 14:00 0人报名