JEB's Blog » MySQL http://blog.james.rcpt.to Scribblings of a Techie Fri, 23 Jul 2010 16:04:18 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 How to convert IPv4 to IPv6 in MySQL http://blog.james.rcpt.to/2010/07/08/hwo-to-convert-ipv4-to-ipv6-in-mysql/ http://blog.james.rcpt.to/2010/07/08/hwo-to-convert-ipv4-to-ipv6-in-mysql/#comments Thu, 08 Jul 2010 14:10:59 +0000 james http://blog.james.rcpt.to/2010/07/08/hwo-to-convert-ipv4-to-ipv6-in-mysql/ If you original IPv4 address is in an unsigned long called “IPv4“, then…

select concat("0:0:0:0:0:0:", LPAD(CONV(substring_index(inet_ntoa(IPv4), '.', 1), 10, 16), 2, "0"), LPAD(CONV(SUBSTRING_INDEX(SUBSTRING_INDEX( inet_ntoa(IPv4) , '.', 2 ),'.',-1), 10, 16), 2, "0"), ":", LPAD(CONV(SUBSTRING_INDEX(SUBSTRING_INDEX( inet_ntoa(IPv4) , '.', 3 ),'.',-1), 10, 16), 2, "0"), LPAD(CONV(SUBSTRING_INDEX(SUBSTRING_INDEX( inet_ntoa(IPv4) , '.', 4 ),'.',-1), 10, 16), 2, "0")) as IPv6 from Log3NF.Access limit 1000;

]]> http://blog.james.rcpt.to/2010/07/08/hwo-to-convert-ipv4-to-ipv6-in-mysql/feed/ 0 MySQL Query Cache: still waiting for duplicate query checking http://blog.james.rcpt.to/2009/05/13/mysql-query-cache-still-waiting-for-duplicate-query-checking/ http://blog.james.rcpt.to/2009/05/13/mysql-query-cache-still-waiting-for-duplicate-query-checking/#comments Wed, 13 May 2009 00:26:05 +0000 james http://blog.james.rcpt.to/?p=185 Way, way back in 2005 (4 years and counting) I finally reported a bug into the then MySQL 5.0 about an issue I was seeing (often) on high volume sites where a single query, if not in the query cache, but spawned from two (or more) simultaneous threads would both be executed in full; this is instead of one execution, and then the query cache being populated.

Reference: Bug 15044, and WorkLog 1293.

I had been seeing this for… well, years before hand, but considered it to be “just me”. Since I filed that bug, others have come forward and said they have seen the same issue.

Now, with the Oracle/Sun merge, and Sun having shelled out to “purchase” MySQL, we see a miraculous MySQL 5.4 being drafted together. Its good; but it appears to be a simple crowd pleaser that should have happened years ago – integrate in some very popular performance improvements (notably from Google’s code repository). If code is being contributed, and it works, why wasn’t this done earlier? And if not earlier, why now? Smokescreen? Last ditch effort before the project is canned by its new owner? Of course, this has been circulating for a while; I’m not posting this later after that’s been in the news for a few weeks now.

What is interesting is the “Refactoring MySQL” project being discussed. Where does this leave MySQL 6 – a little abandoned from here. And then with MariaDB and Drizzle now forked and picking up attention (external to MySQL/Sun/Oracle), it seems the entire thing is just becoming a mess. Drizzel is supposed to be the performance version – but with the google patches being integrated, perhaps the core MySQL branded project is catching up?

What’s looking clearer is: Postgres. From my perspective, its worse for MySQL in Debian. Lenny (stable now) has MySQL 5.0. The Experimental repo has 5.1 (5.1.34), but this hasn’t even transitioned to Unstable yet!

Here’s what I’d like to see:

  1. Someone picks up Bug 15044/WorkLog 1293.
  2. 5.4 goes STABLE from MySQL/Sun/Oracle real soon now, with or without my pet qcache bug/feature – it’s a big enough win for multi-core systems as it stands
  3. Debian moves MySQl 5.1 from experimental straight to Unstable – can the mysql-server-5.1 package can coexist with mysql-server-5.0?
  4. Debian also adds, along side the MySQl 5.0 and 5.1 servers, the 5.4 into Unstable, and 6.0 into Experimental.
]]> http://blog.james.rcpt.to/2009/05/13/mysql-query-cache-still-waiting-for-duplicate-query-checking/feed/ 0