The only criticism of the SUN/MySQL deal I could possibly give is that MySQL is still on the early phase of an exponential adoption curve and I think they’ve got lots of growth yet to come. But really, a billion dollars has a lot, if not most, of that growth factored into the price already. Think of what they get, huge mindshare in a 30,000 person company with an established presence and sales channel throughout the world. They get that mindshare because that same company is one that has struggled to find the next big thing, the next huge thing that is going to change the landscape of enterprise IT. Well they’ve found it. And they’re going to get to work on making it happen.
SUN Microsystems just bought MySQL. I don’t know much about SUN internals, but I’m not sure how the company resolves being the primary developer of 2 differing DBMS’s. Since those are the top 2 open source DBMS’s (and there aren’t really any other ones out there, as I don’t count sqlite as a DBMS), there could be a real conflict of interest.
At the November MySQL User Group, Patrick Galbraith ran into a problem where binlog-do-db was duplicated. It manifests itself like this…Well, it’s a bug. Patrick confirmed that upgrading fixed his bug. Unfortunately, this is an enterprise release. Even more sadly, http://www.dorsalsource.org does not have the source or binaries for the most recent Enterprise version, MySQL 5.0.54.
With this particular client, I ran a SHOW STATUS, waited 100 seconds, and ran it again. Handler_read_first jumped by about 53. So I wrote down in my notes: first in the index…every other second. Lots of table scans? As soon as I wrote it down I said, “That’s a haiku!” I counted syllables, and it works, but only if you pronounce “Every” with 3 syllables.
The listing of Dynamic System Variables on the MySQL Reference Manual’s page is supposed to show those variables you can change on-the-fly. The link at the top of this post, links to the 4.1 version of the manual, just in case folks are thinking I’m using a newer manual version. Mind you, I have this problem with 5.0.45 as well as 4.1.20.
The “sla” in mysqlsla stands for “statement log analyzer”. This does a much better job than mysqldumpslow of analyzing your slow query log. This is really good for weeding out pesky entries in the slow query log that you do not care about. In this case, I’m using –slow to read the slow query log at the filename specified, –flat to flatten all the text to lowercase (basically case-insensitive matching) and –sort at to sort by “average time”.
I’ve been checking out a new client environment. My mission is to figure out some of the characteristics of the queries being run, and if they’re “good” or “bad”. In my arsenal of “tools I really want to check out” has been Maatkit’s Query Profiler, it profiles a batch of queries, without granularity (at least not the way I ran it) to see what query is doing what. So I ran this against a production machine, read my results here
If you are wondering what the differences are between MySQL: SOUNDS LIKE and Full-Text search, look no further.
With the popularity of multi-core machines (and innodb_thread_concurrency) on the rise, we are seeing more issues with adaptive hash index semaphore deadlocks. I guess there finally is a benefit to having MySQL Enterprise — the ability to disable InnoDB’s Adaptive Hash. If you want, you can hack the source code and compile your own version of MySQL. Only 4 file changes are needed to make the workaround happen, and the changes are detailed here.
I’m a MySQL DBA trying to draw a map of this new (to me) world called Oracle. The other day I was trying different things with Oracle, like (but not limited to) issuing kill -9 to random Oracle processes to see what would happen (on my own box of course!). I was a little surprised by the results. They’re probably no news for most of you guys, but it is new to me, and I’d like to share my findings with other MySQL guys around the planet.