There’s one bottleneck in MySQL/InnoDB that ultimately sucks. It sucked in 4.0, sucked in 5.0, sucks in 5.1 with newest InnoDB plugin. Opening tables has been a bottleneck on machines that have thousands of tables all the time (as LOCK_open is being held during the process), and while there was a table being opened, everything else would stall on the machine.

It can simply take hours on such systems just to open tables – and the major portion of time spent is randomly diving into InnoDB tables to populate index statistics. It obviously sounds like low hanging fruit – as statistics aren’t needed while you are opening a table, they’re needed just for querying the table.

So, I threw in few thousand tables to my machine, and tried opening them with ten connections. Standard InnoDB code was opening 13.5 tables a second. After spending few minutes and moving …

In text:

1. Download “mysql-connector-net-6.2.2-src.zip”  from http://dev.mysql.com/downloads/connector/net/ and extract the zip file.  Note that we need ‘src’ version of library if we want to debug in visual studio.

2. Open your Visual Studio Solution and add  “Mysql.data.csproj”  located at  “MySql.Data\Provider\” inside the extracted archive.

3. Add this project’s reference to your project (mysql.data).

4. Now you can debug into mysql.data methods.

In the earlier post we learned how to push jobs from the client to the worker. What we will try to do here is to use php script - the same worker we developed last time to process queries in the mysql server. That is to use gearman to process requests posted inside mysql client. We would need the mysql UDFs for gearman which could be downloaded from the gearman.org

MySQL has a couple of sanity-check features to help keep you from doing dumb things.

• max_join_size is a configuration option for the mysqld server program. It throws an error if you write a query that the optimizer estimates will examine more than this number of rows.
• –safe-updates is a command-line option to the mysql client program. It throws an error if you write an UPDATE or DELETE without a) a WHERE clause that refers to an indexed column or b) a LIMIT clause. It also sets the max_join_size and select_limit variables.

The –safe-updates mysql client option actually sets three variables server-side. Let’s see the effects. First, the defaults:

MySQL has a couple of sanity-check features to help keep you from doing dumb things. max_join_size is a configuration option for the mysqld server program. It throws an error if you write a query that the optimizer estimates will examine more than this number of rows. –safe-updates is a command-line option to the mysql client program. It throws an error if you write an UPDATE or DELETE without a) a WHERE clause that refers to an indexed column or b) a LIMIT clause.

I've got some code in lp:drizzle/staging right now that's on its way (barring major catastrophes) to trunk. It's not code that does anything sexy as far as the actual running server is concerned. It's a code cleanup branch.

Anyway - short story being - everything from mysys and mystrings that is actually part of public APIs has been moved into drizzled/ proper. Everything else has been moved into drizzled/internal. None of the headers from drizzled/internal are installed... so none of the headers in drizzled/ should be using any of them. Combine this with the past week's removal of both server_includes.h and global.h, and we're getting pretty close to having fully consumable headers.

Which brings me to:

In doing this, I noticed a bunch of things that either need to be fixed, still need to be deleted, or need to be put behind a namespace so that including our headers doesn't strangely and unexpectedly …

UPDATE This matter was more tricky than it appeared at first sight. As Bug#49861 shows, several MySQL engineers were …

Users toggling between MySQL and Postgres are often confused by the equivalent commands to accomplish basic tasks. Here's a chart listing some of the differences between the command line client for MySQL (simply called mysql), and the command line client for Postgres (called psql).

When I was younger, I remember hearing the phrase "too big to fail" being used to describe very large companies in the US, often financial institutions of some type. At the time I had thought the meaning of this phrase was an indicator of size of a company, the diversity of it's business dealings, and it's financial reserves. The idea was that, as the size of the company grew, its ability to withstand a hit in any one market would increase, because other areas of the business could keep it going. Last year as the financial crisis was getting into full swing and our government was looking at bailing out companies, this phrase took on a fairly different meaning, more so referring to the idea that a company had grown so big and so well integrated into the daily economy that it's failure would be catastrophic to the larger financial ecosystem. Or as I more cynically thought of it, the company had grown so big it was able to grease politicians at every …

I request every visitor of this blog to read below article & support Monty

http://monty-says.blogspot.com/2009/12/help-saving-mysql.html7TKU66CE8V5W