by Peter Zaitsev | Jan 31, 2009 | Percona Events
Recently my attention was brought to this bug which is a nightmare bug for any consultant. Working with production systems we assume reads are reads and if we’re just reading we can’t break anything. OK may be we can crash the server with some select query...
by Peter Zaitsev | Sep 12, 2008 | Insight for DBAs
What bug makes you to recommend upgrading most frequently ? For me it is this bug which makes it quite painful to automate various replication tasks. It is not the most critical bug by far but this makes it worse – critical bugs would usually cause upgrades...
by Peter Zaitsev | Sep 11, 2008 | Insight for DBAs
How would you expect AUTO_INCREMENT to work with MERGE tables ? Assuming INSERT_METHOD=LAST is used I would expect it to work same as in case insertion happens to the last table… which does not seems to be the case. Alternatively I would expect AUTO_INCREMENT to...
by Peter Zaitsev | Sep 4, 2008 | Percona Events
Over a year ago I wrote about pretty nasty Innodb Recovery Bug. I ran in the same situation again (different system, different customer) and went to see the status of the bug… and it is still open. You may thing it is minor issue but in fact with large buffer...
by Peter Zaitsev | Sep 2, 2008 | Insight for DBAs
As you might know ANALYZE TABLE just quickly updates table statistics using index dives, unlike with MyISAM when it scans indexes holding table lock for long period of time. So ANALYZE TABLE should be very fast and non intrusive operation doing just little update on...
by Peter Zaitsev | Aug 1, 2008 | Insight for Developers
JOINs are expensive and it most typical the fewer tables (for the same database) you join the better performance you will get. As for any rules there are however exceptions 🙂 The one I’m speaking about comes from the issue with MySQL optimizer stopping using...
by Peter Zaitsev | Jul 19, 2008 | Percona Events
MySQL 5.1 was in RC stage for around 10 months now finally planned to be released as GA soon. As Monty Says MySQL 5.1.26 will be renamed as GA if no serious bugs are discovered. Lets help MySQL to ensure GA release will be indeed GA quality and support Monty in his...
by Vadim Tkachenko | May 20, 2008 | Insight for DBAs
Remembering that I did RENAME DATABASE in MySQL 5.1.21 and found it useful I tried it with 5.1.24 (I was playing with 20GB InnoDB database, so dumping is not fastest way) and all my tries finished with “Syntax error”. So RTMF and documentation says...
by Peter Zaitsev | Apr 4, 2008 | Insight for Developers
We have an application which stores massive amount of urls. To save on indexes instead of using URL we index CRC32 of the URL which allows to find matching urls quickly. There is a bit of chance there would be some false positives but these are filtered out after...
by Peter Zaitsev | Mar 16, 2008 | Insight for DBAs
What MySQL honestly was never good at is giving good helpful error messages. Start with basics for example – The error message in case of syntax error gives you information about tokens near by but little details: mysql> select * from user oder by pwd; ERROR...
by Peter Zaitsev | Jan 29, 2008 | Insight for DBAs
As you might know even if you’re only using Innodb tables your replication is not completely crash safe – if Slave MySQL Server crashes/power goes down it is likely for relay logs to run out of sync (they are not synced to the disk) plus position on the...
by Andrew Aksyonoff | Jan 10, 2008 | Insight for Developers
Sometimes you need to work with big numbers in PHP (gulp). For example, sometimes 32-bit identifiers are not enough and you have to use BIGINT 64-bit ids; e.g. if you are encoding additional information like the server ID into high bits of the ID. I had already...
by Peter Zaitsev | Nov 13, 2007 | Insight for DBAs
People are sometimes contacting me and asking about bugs like this which provide a trivial way to crash MySQL to the user with basic privileges and asking me what to do. My answer to them is – there is nothing new to it and they just sit should back and relax 🙂...
by Peter Zaitsev | Oct 22, 2007 | Percona Events
If you have been MySQL User for many years you might remember the times when MySQL had “zero bugs policy”, this is when all known bugs really were fixed before release was made. To be honest at that time bugs were reported via bugs mailing list not via...
by Vadim Tkachenko | Oct 12, 2007 | Uncategorized
We many times wrote about InnoDB scalability problems, this time We are faced with one for MyISAM tables. We saw that several times in synthetic benchmarks but never in production, that’s why we did not escalate MyISAM scalability question. This time working on...
by Peter Zaitsev | Oct 4, 2007 | Insight for DBAs
Recent couple of days our team was pointed to number of bugs in MySQL 5.0 which again seriously shakes the confidence in both MySQL Quality Control and bug fix promptness. Let me just take couple of bugs as examples: Triggers broken with auto-increment columns for...
by Peter Zaitsev | Sep 12, 2007 | Insight for DBAs
Monty Taylor posted interesting investigation of the fact read_buffer_size variable affects connection speed. This is not something you would expect right ? me too. Not only global user data is expected to be cached on startup but even if it is not why would you do...
by Peter Zaitsev | Aug 16, 2007 | Benchmarks, Insight for DBAs
As you might know while running GROUP BY and some other kinds of queries MySQL needs to create temporary tables, which can be created in memory, using MEMORY storage engine or can be created on disk as MYISAM tables. Which one will be used depends on the allowed...
by Peter Zaitsev | Aug 12, 2007 | Insight for DBAs
I start to see applications being built utilizing VIEWs functionality which appeared in MySQL 5.0 and quite frequently VIEWs are used to help in writing the queries – to keep queries simple without really thinking how it affects server performance. Even worse...
by Vadim Tkachenko | Aug 6, 2007 | Insight for Developers
Recently we were puzzled by question how query_cache works with column level privileges. The question was appeared as we discovered function query_cache_send_result_to_client is called before real parsing of query, so at the moment of execution the query_cache is not...
