Showing entries 18361 to 18370 of 44106
« 10 Newer Entries | 10 Older Entries »
Virident FlashMAX MLC in tpcc-mysql workload

As I mentioned in previous post on Virident FlashMAX MLC, beside sysbench benchmark, I also run tpcc-mysql (to compare performance Virident FlashMAX vs Fusion-io ioDrive Duo)

The report with results is there: http://www.percona.com/files/white-papers/virident-mlc-tpcc.pdf

The graphical result for tpcc-mysql 5000W:

My conclusions from this benchmark:

  • Virident FlashMAX provides stability of performance and reveals a denser throughput.
  • In addition to stability, in many cases there is also a better throughput in MySQL (up to 40\%) using the Virident …
[Read more]
Understanding the unique_subquery optimization

If you use the EXPLAIN SELECT statement to see how your subqueries are treated by MySQL, you may sometimes meet the "unique_subquery" optimization. Here is how the manual describes it:
"unique_subquery: this type replaces ref for some IN subqueries of the following form: value IN (SELECT primary_key FROM single_table WHERE some_expr); unique_subquery is just an index lookup function that replaces the subquery completely for better efficiency".Few weeks ago, while I was reviewing a patch fixing a bug in unique_subquery, I got a "simplification" pulsion. I told myself that:

  •  unique_subquery is an optimization for a special case of simple subqueries (single inner …
[Read more]
Avoiding auto-increment holes on InnoDB with INSERT IGNORE

Are you using InnoDB tables on MySQL version 5.1.22 or newer? If so, you probably have gaps in your auto-increment columns. A simple INSERT IGNORE query creates gaps for every ignored insert, but this is undocumented behaviour. This documentation bug is already submitted.

Firstly, we will start with a simple question. Why do we have gaps on auto-increment columns? Secondly, I will show you a trick to mimic the INSERT IGNORE behaviour without losing auto increment values. Let’s start!

Why do we have gaps?

InnoDB checks an auto_increment counter on the table and if a new value is needed, increments that counter and assigns the new value to the column. Prior to MySQL 5.1.22 InnoDB used a method to access that counter values called “Traditional“. This one uses a special table lock called AUTO-INC that remains until …

[Read more]
Special mysqldump fingerprinting rule in pt-query-digest

The pt-query-digest tool has a number of special cases that affect how it “fingerprints” queries when it groups similar queries together to produce an aggregated report over the group. One of these is a special rule for queries that appear to come from mysqldump, of the following form:

SELECT /*!40001 SQL_NO_CACHE */ * FROM `users`

All such queries will be fingerprinted together and presented in a single class of queries. I remember many instances where mysqldump queries crowded the report of the “most important” queries and just caused other queries to be excluded. Grouping them together made it obvious that mysqldump’s load on the server was a problem, but didn’t obliterate other interesting things we wanted to see in the report.

Further Reading:

[Read more]
Re: MySQL 5.5.18 Debian packaging now available

That's very good news!

Will Bug #60833 (APT/YUM Repository for MySQL) also be fixed soon?

http://bugs.mysql.com/bug.php?id=60833

Re: MySQL 5.5.18 Debian packaging now available

That's very good news!

Will Bug #60833 (APT/YUM Repository for MySQL) also be fixed soon?

http://bugs.mysql.com/bug.php?id=60833

Special mysqldump fingerprinting rule in pt-query-digest

The pt-query-digest tool has a number of special cases that affect how it “fingerprints” queries when it groups similar queries together to produce an aggregated report over the group. One of these is a special rule for queries that appear to come from mysqldump, of the following form: SELECT /*!40001 SQL_NO_CACHE */ * FROM `users` All such queries will be fingerprinted together and presented in a single class of queries. I remember many instances where mysqldump queries crowded the report of the “most important” queries and just caused other queries to be excluded.

MySQL multi-site operations with Tungsten Enterprise geo-clustering -- Webinar 12/1

Spreading data across multiple sites solves some important problems, including ensuring business continuity, disaster recovery (DR) as well as availability of applications spread across the globe. Join us to learn how Tungsten Enterprise can start with existing, off-the-shelf MySQL databases and build them out to create easy-to-manage clusters spanning multiple hosts and sites. We'll cover the

Great Interactive Map of NYC Startups

Read the original article at Great Interactive Map of NYC Startups

Business Insider posted this spectacular interactive google map of our amazing Startup Ecosystem here in New York City.  Wow!

Check out the full list of NYC Startups in the original article.


View NYC Startups in a larger map

For more articles like these go to MySQL Expert, Linux, EC2 & …

[Read more]
MySQL and Debian Linux

It is available now ! MySQL 5.5.18 now offers Debian Linux (.deb) packages.

They are available via the http://dev.mysql.com/downloads/mysql site !


Finally the Debian community can upgrade easily to MySQL 5.5 !

Showing entries 18361 to 18370 of 44106
« 10 Newer Entries | 10 Older Entries »