解惑

解己之惑,解人之惑

标签:数据库

WordPress Database Backup不好用

今天回来的第一件事情就是备份数据库,原来的插件不好用,备份出来的文件都不能打开,CRC出错,而且经常备份到一半就停止了,下载了最新的2.2.2版本,不会停止了,但是文件还是不能打开。

没有办法,登录到盘古的cPanel,发现有 phpMyAdmin,用它的导出功能把数据库导出来了,还是发现一个不足的地方,它的文件编码是GBK,那些数据库脚本的注释可以正常显示,但是数据里面都是乱码,用UTF-8重新load,发现数据可以正常显示为中文,但是注释是乱码了。

Inner join的问题

这个是最近感觉最有成就的一个发现了。
我们的系统有一个存储过程执行一个很核心的查询功能,但是在某些情况下非常的慢,而且最近QA一直在做性能测试,每天发送大量的数据,导致系统的性能越来越慢,我原来也曾经优化过这个存储过程,建了很多索引,解决了那个时候管理员用户的问题,但是现在很多普通用户的问题更加的严重,经过调试发现第一步的查询非常的慢,打印出结果来发现那个查询会产生9千万条纪录,而且会使用多达6G的硬盘空间来存储临时数据,后来加了个distinct解决了空间问题,空间使用不到6M,但是速度还是很慢,使用Tuning Advisor优化也没有什么帮助,后来我想了下为什么会产生那么多相同的数据呢?仔细看了下SQL,发现它用6个表进行inner join,但是只从其中的四个表各取一个字段,我就把另外的两个表从inner join移到where条件了,查询时间从6分钟(问题最大的一个用户)减少到6秒,呵呵

数据库可移植性重要吗?

对于大部分应用而言,数据库可移植性可能不太重要,而一些完全使用ORM的应用可能也问题不大,但是一旦需求来了,它就变得非常的重要,现在我们就遇到了这样的需求。
我们原来一直使用Oracle,也从来没有想到要更换数据库类型,所以我们一直心安理得的使用各种Oracle优化技巧来优化我们的SQL(我们的系统的性能要求也比较高),现在有个新客户,要求使用SQL Server,这下就麻烦大了,初步估计需要5000个小时!
这个变化也影响到我们做的水晶报表,原来没有考虑数据库迁移,所以选择数据库连接的时候直接选择的就是Oracle服务器,而不是建一个ODBC的数据源,而水晶报表的数据库配置是不能随便修改的,不说更换数据库类型,就是更换一下服务名都不行。

PS:据说微软愿意为我们的数据库迁移支付一部分的成本,呵呵,果然是财大气粗啊。

WP-ShortStat是数据库空间杀手

一直很奇怪数据库空间为什么一直在快速增加,今天备份数据库的时候发现数据库已经到35M了,把备份文件看了下,发现wp_ss_stats表几乎占据了整个数据库的使用量,删除这个表的数据后,数据库空间下降到只有1M多一点,呵呵,果断的停用了这个插件,还是使用外部的访问统计好了。我想WP-ShortStat可能只适用与每天只有几个点击量的Blog?我的这个Blog的访问量也不是很大,每天的点击数最多300(Google Analytics统计数据),三个多月的数据量就有35M,要是一天的点击量上千,那还不是早暴了?

完成轮子的第三个部分-连接池

其实也不是连接池,而且我还是不太清楚Connection的close应该干嘛,简单的实现了DataSource,并使用动态代理实现Connection的复用,Connection使用几次以后或者使用一段时间以后再真正的关闭。

代码如下:
阅读全文

连接池中的Connection.close()应该干什么?

本来想写一个简单的数据库连接池的,上网搜索了一下别人的实现,也看了一些开源的实现,感觉有些问题,那就是连接池中的Connection.close()应该干什么?按照API的说明,这个方法应该释放数据库和JDBC的资源,但是这样的话,连接池中的连接就要重新建立,似乎没有起到pool应有的作用,如果代码不进行close操作,交给其它的地方释放又不太安全。难到说我原来的代码习惯都是错的?取得一个Connection后,使用完不需要close,而是把相关的ResultSet和Statement关闭就行了?
找了很多文章,都没有提到这个问题。
目前来看,我不用关注那么多了,可能的解决方法就是让框架来执行数据库操作,执行完以后commit,关掉ResultSet和Statement,Connection保持连接,一定时间以后再close。

© 2019 解惑

本主题由Anders Noren提供向上 ↑