Andrii, Ivan and the rest of the family have now started settling in in Heidelberg. Georg Richter has found an apartment for them close to the hospital, and they will move there in a few days.

The first round of tests and examinations (blood tests, bone marrow punctation) has been concluded, but I won’t share any speculations on this until we’ve got them confirmed. The examinations will continue, and the best case scenario is that a transplant could happen 8 - 10 weeks from now.

Currently donations for Ivan are at about EUR 90,000. Most of it comes from Sun Dolphins (former MySQLers) and to some extent from Sun Classic employees. And more than 25% represent donations from the MySQL Community! Thanks everyone! The German clinic expects at least an additional EUR 150,000 to be needed, though, so I encourge those of you who haven’t contributed yet to press the “Donate” button at the end of the article on our official Ivan page.

Links:

• http://www.mysql.com/about/help-ivan.html
• http://blogs.mysql.com/kaj/2008/07/21/ivan-nikitin-has-arrived-in-germany/
  
• http://en.wikipedia.org/wiki/Bone_marrow#Donation_and_transplantation_of_bone_marrow
• http://en.wikipedia.org/wiki/Hematopoietic_stem_cell_transplantation

The OpenRemote team also includes the creator of Asterisk Mark Spencer, JBoss veterans Juha Lindfors, Christian Bauer, Java X10 project creator Wade Wassenberg, and Linux Home Automation founder Neil Cherry.

Together they, and others, plan to create a complete open source home automation including the OpenRemote Controller hardware, OpenRemote Console Applications to make use of the iPhone and iTouch as a universal remote (although any device with browser will work), the OpenRemote Manager, and the Beehive Database.

As Marc notes (”I have invented Professional Open Source, have you heard of it?”) he has also created OpenRemote Inc to support the community via debt funding and is exploring different potential business models to generate revenue.

He doesn’t appear to be in a hurry to do so, however. “This is first and foremost a community effort and what will come of it will come of it. Planning to far ahead would be counterproductive and futile,” he writes. “Figuring out the business model, this is one thing I can help with. But for right now, let’s focus on a community. Without a community, there is no OSS model. The community is what you do with it.”

Introducing Drizzle http://krow.livejournal.com/602409.html

In short it is...

• ... for Web based apps.
• ... for Cloud components.
• Databases without business logic (aka stored procedures).

...more

read more

mysql> select * from information_schema.mysql_cached_queries\G
*************************** 1. row ***************************
           STATEMENT_ID: 1
            SCHEMA_NAME: test
         STATEMENT_TEXT: select count(*) from world.city
    RESULT_BLOCKS_COUNT: 1
     RESULT_BLOCKS_SIZE: 512
RESULT_BLOCKS_SIZE_USED: 106
1 row in set (0.00 sec)

CONFIGURE_LINE="./configure '--prefix=/usr/local/mysql' '--localstatedir=/usr/local/mysql/data' '--libexecdir=/usr/local/mysql/bin' '--with-comment=MySQL Community Server (GPL)' '--with-server-suffix=' '--enable-thread-safe-client' '--enable-local-infile' '--enable-assembler' '--with-pic' '--with-fast-mutexes' '--with-client-ldflags=-static' '--with-mysqld-ldflags=-static' '--with-zlib-dir=bundled' '--with-big-tables' '--with-ssl' '--with-readline' '--with-embedded-server' '--with-partition' '--with-innodb' '--without-ndbcluster' '--with-archive-storage-engine' '--with-blackhole-storage-engine' '--with-csv-storage-engine' '--without-example-storage-engine' '--with-federated-storage-engine' '--with-extra-charsets=complex' 'CC=ccache gcc -static-libgcc' 'CFLAGS=-g -O3' 'CXXFLAGS=-g -O3' 'CXX=ccache gcc -static-libgcc'"

While comparing sysbench runs using two different versions of MySQL 5.1, I noticed a big difference in the system utilization. One version had much more idle time than the other. This difference was much more apparent with high thread counts on machines with lots of CPU. A look at the system calls showed a large number of lwp_park system calls. That is, threads were being put to sleep.

bash # $ dtrace -qn 'syscall:::entry{@c[probefunc]=count()}' -n tick-5s'{trunc(@c, 10);exit(0)}'

  p_online                                                       1535
  ioctl                                                          2255
  fcntl                                                          6134
  priocntlsys                                                    6462
  write                                                          6492
  read                                                          12775
  yield                                                         19065
  gtime                                                        313927
  pollsys                                                      321074
  lwp_park                                                     951749

              libc.so.1`__lwp_park+0x10
              libc.so.1`cond_wait_queue+0x28
              libc.so.1`cond_wait+0x10
              libc.so.1`pthread_cond_wait+0x8
              mysqld`os_event_wait_low+0x3c
              mysqld`sync_array_wait_event+0x1c0
              mysqld`mutex_spin_wait+0x1c4
              mysqld`mutex_enter_func+0x1c
              mysqld`rw_lock_x_lock_func+0x3b4
              mysqld`mtr_x_lock_func+0x10
              mysqld`fsp_get_available_space_in_free_extents+0x30
              mysqld`int ha_innobase::info(unsigned)+0x164
              mysqld`bool make_join_statistics(JOIN*,TABLE.. +0x180
              mysqld`int JOIN::optimize()+0x670
              mysqld`bool mysql_select(THD*,Item***,TABLE_.. +0x224
              mysqld`bool handle_select(THD*,st_lex*,selec.. +0xc4
              mysqld`bool execute_sqlcom_select(THD*,TABLE.. +0x1c8
              mysqld`int mysql_execute_command(THD*)+0x380
              mysqld`bool Prepared_statement::execute(Stri.. +0x29c
              mysqld`bool Prepared_statement::execute_loop.. +0xbc

/*
  assuming the table keeps shared actual copy of the 'info' and
  local, possibly outdated copy, the following flag means that
  it should not try to get the actual data (locking the shared structure)
  slightly outdated version will suffice
*/
#define HA_STATUS_NO_LOCK        2

I compared against MySQL 5.0 and saw that this particular lock was not held when ha_innobase::info() was called. Searching through the commit logs I found that this was introduced by Bug#32440.

Quickly hacking the code to revert to the old behaviour gave a big boost in performance. Hence I filed Bug #38185 ha_innobase::info can hold locks even when called with HA_STATUS_NO_LOCK. Luckily its a very small change and a fix is already in progress.

Moral of the story? A simple contented lock can bring down your performance by quite a lot.]]> Thu, 24 Jul 2008 01:55:08 +0000 Neelakanth Nadgir tag:trainedmonkey.com,2008-07-23:3150 http://trainedmonkey.com/2008/7/23/need_anything_dampened_ drizzle is an interesting new development in the mysql landscape. brian aker, who came along to sun microsystems in the acquisition but is actually now part of sun labs, not the database group, has taken the mysql server and started to strip it down to the bare metal. he isn?t working alone, of course, but has picked up some contributors during the stealthy period before they announced it at oscon on tuesday.if you were paying attention the other day, you may have dug around my launchpad code page and noticed that i had a branch of drizzle where i was applying some fixes to make it build on mac os x. that should be merged into the main tree soon, so that branch will soon be retired. i?m not sure what i might try to do next.drizzle isn?t something i am working on officially, but i can?t help but try to push things into some directions that i think would be fruitful. i certainly feel like i have a better shot of shifting its inertia than that of the mysql server. drizzle is an interesting new development in the mysql landscape. brian aker, who came along to sun microsystems in the acquisition but is actually now part of sun labs, not the database group, has taken the mysql server and started to strip it down to the bare metal. he isn?t working alone, of course, but has picked up some contributors during the stealthy period before they announced it at oscon on tuesday.

if you were paying attention the other day, you may have dug around my launchpad code page and noticed that i had a branch of drizzle where i was applying some fixes to make it build on mac os x. that should be merged into the main tree soon, so that branch will soon be retired. i?m not sure what i might try to do next.

drizzle isn?t something i am working on officially, but i can?t help but try to push things into some directions that i think would be fruitful. i certainly feel like i have a better shot of shifting its inertia than that of the mysql server.]]> Wed, 23 Jul 2008 23:07:12 +0000 Jim Winstead http://www.xaprb.com/blog/2008/07/23/using-base-instead-of-acid-for-scalability/ http://www.xaprb.com/blog/2008/07/23/using-base-instead-of-acid-for-scalability/ My editor Andy Oram recently sent me an ACM article on BASE, a technique for improving scalability by being willing to give up some other properties of traditional transactional systems. It’s a really good read. In many ways it is the same religion everyone who’s successfully scaled a system Really Really Big has advocated. But this is different: it’s a very clear article, with a great writing style that really cuts out the fat and teaches the principles without being specific to any environment or sounding egotistical. He mentions a lot of current thinking in the field, including the CAP principle, which Robert Hodges of Continuent first turned me onto a couple months ago. It has been proven formally, though I have not read the proof myself. One of the most important concepts he advances is giving up the illusion of control. As programmers and DBAs, I think we may tend to like control too much. Foreign keys are a perfect example. I think the point here is that these things make you feel safe, but they don’t really make you safe. Just as with so many things in life, recognizing our inability to really control the systems we build is key to working with their strengths — instead of trying to bind them with iron bands. Another great point is idempotency. This is a great way to help avoid problems with MySQL replication, by the way. I’ll leave the “why” as an exercise for the reader, but let me just point out that the file MySQL uses to remember its current position in replication is not synced to disk, so it will almost certainly get out of whack if MySQL dies ungracefully. (Google has solved this problem.) A highly recommended read — worth more than most case studies about how specific companies have scaled their specific systems.ACID, ACM, Andy Oram, BASE, CAP, Continuent, foreign keys, mysql, replication, Robert Hodges, scaling, transactions My editor Andy Oram recently sent me an ACM article on BASE, a technique for improving scalability by being willing to give up some other properties of traditional transactional systems.

It’s a really good read. In many ways it is the same religion everyone who’s successfully scaled a system Really Really Big has advocated. But this is different: it’s a very clear article, with a great writing style that really cuts out the fat and teaches the principles without being specific to any environment or sounding egotistical.

He mentions a lot of current thinking in the field, including the CAP principle, which Robert Hodges of Continuent first turned me onto a couple months ago. It has been proven formally, though I have not read the proof myself.

One of the most important concepts he advances is giving up the illusion of control. As programmers and DBAs, I think we may tend to like control too much. Foreign keys are a perfect example. I think the point here is that these things make you feel safe, but they don’t really make you safe. Just as with so many things in life, recognizing our inability to really control the systems we build is key to working with their strengths — instead of trying to bind them with iron bands.

Another great point is idempotency. This is a great way to help avoid problems with MySQL replication, by the way. I’ll leave the “why” as an exercise for the reader, but let me just point out that the file MySQL uses to remember its current position in replication is not synced to disk, so it will almost certainly get out of whack if MySQL dies ungracefully. (Google has solved this problem.)

A highly recommended read — worth more than most case studies about how specific companies have scaled their specific systems.

From there, Giuseppe gave a short talk on what it’s like to work at MySQL, and then we moved on to the topic of the user group meeting, “What is MySQL Cluster Good For?”

The slides for the talk are downloadable in PDF Format 61kB and Flash (SWF) format, 31kB

The video can be played at http://technocation.org/node/572/play and downloaded (404 Mb) at http://technocation.org/node/572/download.

From there, Giuseppe gave a short talk on what it's like to work at MySQL, and then we moved on to the topic of the user group meeting, "What is MySQL Cluster Good For?"

The slides for the talk are downloadable in PDF Format 61kB and Flash (SWF) format, 31kB

read more

Damian Conway is a speaker that should not be missed. He spends his time hacking perl to do fascinating and obscure feats of technology such as time travel. This video is just over an hour of rolling laughter that will entertain you into realizing what a genius Damian Conway is.

Now, most of my exposure is within the MySQL Community, so if folks could pass the links to the video along to other communities, that would be great.

(This video is at 1.0 Mb/sec. Watch the video online at http://technocation.org/node/571/play or download it at http://technocation.org/node/571/download. Please do not download the file if you are on the conference network, these links are not time sensitive.)

Damian Conway is a speaker that should not be missed. He spends his time hacking perl to do fascinating and obscure feats of technology such as time travel. This video is just over an hour of rolling laughter that will entertain you into realizing what a genius Damian Conway is.

Now, most of my exposure is within the MySQL Community, so if folks could pass the links to the video along to other communities, that would be great.

read more

Drizzle was only officially announced yesterday in Drizzle, Clouds, ?What If?? by primary architect Brian Aker. Things move fast. There has been a number of comments from people yesterday including Mark Attwood, Monty Widenus,Monty Taylor,Ronald Bradford, Arjen Lentz, Lewis Cunningham, Jeremy Cole, 451 Group,Matt Asay, Assaf Arkin, SlashDot, Builder.au and MySQL HA.

The Drizzle Launchpad project has reached 5th on a Google Search.

Unfortunately, not all uptake and feedback was positive. The official Wikipedia page for Drizzle was marked for speedy deletion almost instantly, and within a few hours permanently deleted.

As announced at the O'Reilly Open Source Convention, Brian Aker, MySQL's director of architecture, has launched Drizzle, an optimized and trimmed-down version ...

Few would have predicted that we would also see a project that would make the database smaller and lighter, but that is exactly what Drizzle, a new project from Sun’s MySQL director of architecture Brian Aker, is all about.

Drizzle is taking a back-to-the-drawing-board approach to refactoring MySQL by ripping out much of the additional enterprise functionality that has gone into it since version 4.1 and focusing on the demands of a core set of applications.

As Brian explains : “Stored Procedures, Views, Triggers, Query Cache, and Prepared Statements are gone for now. The field types have been simplified and there is an open debate about the SHOW commands (I am falling into the camp that think they may just belong in the client application but not in the server). Will any of this go back in? It is hard to say. The goal right now is to target a certain class of applications/developers and see if this is useful. As an example:

1) Web based apps.
2) Cloud components.
3) Databases without business logic (aka stored procedures).
4) Multi-Core architecture.”

The project also has a more community-centric development philosophy, although it is not clear from the FAQ what the copyright implications are for would-be contributors.

Brian announced the project with the caveat that it is “not looking to be 100% compatible with MySQL” and “certainly not a replacement for MySQL” which is important to consider, but the project clearly has the blessing of MySQL CTO Monty Widenius who has stated that “Drizzle solves many of the problems that MySQL’s development has had for years.”

Among the benefits noted by Monty are:

* “It opens up MySQL development for the community; You no longer have to wait years to get your patches and reasonable extensions into the server.

* Critical bugs that have existed for years can finally get fixed as the development is no longer constrained by unrealistic release schedules that put artificial constraints on things that can be fixed.

* Drizzle will put some MySQL server differentiation on a true test; A bit like Fedora does to Red Hat.

* Drizzle has created new excitement in the MySQL developer community; A lot of people seem to be very enthusiastic to work on it in a true community-oriented manner.

* Developers working on Drizzle is doing drastic refactoring of the server, something that MySQL planned to do years ago but never happened.

* Development decisions is again driven by people that are using the server daily; This will ensure that Drizzle will be faster and more stable than what can be done with current MySQL development model

* Drizzle will target the MySQL core users, the web users, whose requirements have been ignored for years while the core MySQL developers have added features that they don’t need.

* In addition Drizzle will include the latest InnoDB code; You don’t have to wait for MySQL 6.0 or go to the trouble of annually downloadoing and installing the InnoDB plugin from Oracle just to get access to the latest and fastest InnoDB version.”

It is interesting to see Monty mention Drizzle as a potential Fedora-like project, especially given his link to ProvenScaling’s publication of MySQL sources and binaries and a blog post from Peter Zaitsev wondering whether it makes MySQL Community redundant.

It would be wrong to claim that as an official endorsement, but MySQL is clearly not trying to discourage community-led projects while it has also moved its sources to Bazaar and Launchpad to (as Kaj Arno puts it) “expand our external contributor base”.

All in all it is fascinating to see that MySQL, which many would consider one of the more mature open source projects, continues to evolve and experiment, especially now it has more freedom to do so as part of Sun. As Monty says:

“Drizzle is one of the good things that have been made possible by Sun acquiring MySQL. Brian has been working on Drizzle with the blessing and encouragement from Sun’s upper management. We are finding Sun to be open and encouraging of innovation, this has been a good aspect of the acquisition.”

According to new research released today by Bernard Golden (Navica) and O'Reilly Research, there are at least six reasons compelling the rapid rise of open source. Agility and scale, reduced vendor lock-in, quality and security, cost, sovereignty (i.e., Local, not necessarily US-based development), and innovation. No wonder Sourceforge downloads continue to rise.

In one particular area, however, open source shines, in my opinion: The ability to reduce lock-in to a particular vendor. The report suggests:

There is little potential price competition for incumbent vendors: Because locked-in vendors have little fear of being replaced, they are in a position to extract expensive maintenance and upgrade fees, bleeding ever-shrinking IT budgets of precious dollars. For example, Oracle just announced price increases of 20% for its database software (accompanied by increases in ongoing maintenance fees as well), secure in the knowledge that very few enterprises are in a position to resist the increase due to the difficulty of replacing the products.

Whatever the price associated with getting into a relationship with Oracle, Microsoft, SAP, IBM, HP, etc., few enterprise buyers seem to reflect on just how expensive it will be to disengage from that relationship due to lock-in to proprietary technology. Things that may be good for buyers (like SaaS) can be safely avoided by the vendor that owns its customers.

While the company understandably highlights the adoption of PostgreSQL for transaction-intensive applications and its high reliability and performance and scalability EnterpriseDB has done a pretty good job of presenting the results in an unbiased manner.

I couldn’t help feeling that some of the more interesting results are hidden at the end of or buried within EnterpriseDB’s write-up, or even missing entirely, however.

For example, right at the end of its report EnterpriseDB states that “eight three percent have yet to pay for the use of their open source database” which speaks volumes about both the challenge that open source database vendors face in converting users to paying customers and the opportunity that is open to them if they can find a solution.

The company also states that “a majority of respondents indicated that they used an open source database in order to migrate away from their use of Microsoft SQL Server and Oracle commercial databases” which is technically accurate but a little misleading. It further adds that “less than one percent indicated they moved off of IBM DB2 to an open source database. Microsoft SQL Server was the highest at eleven percent while Oracle was at six percent.”

EnterpriseDB doesn’t tell us how many migrated from ‘other databases’ (which was the other answer available) but I think it’s fair to say that the majority of respondents in fact indicated that they had not used an open source database in order to migrate away from a proprietary database.

This supports the results we saw in our own recent open source database report as well as recent results from a Forrester survey. As I told eWeek in response to that survey, “Even EnterpriseDB, which offers proprietary Oracle-compatible functionality on top of PostgreSQL, is pitched more at Oracle avoidance projects than Oracle replacement projects.”

Back to EnterpriseDB’s survey, and Sam Dean at OStatic has questioned the finding that “only nine percent of respondents said they prefer commercial databases to open source ones”. The answer lies in the question being asked, which was “What prevents you or your company from using an open source database?”.

Clearly the result Sam mentions doesn’t mean that 81% of respondents prefer open source databases, but it does mean that only 9% have a preference for commercial databases that would prevent the use of open source databases.

While 85% indicated that “nothing prohibits their company from using an open source database” likewise that doesn’t mean that 85% are actually using an open source database.

Unfortunately EnterpriseDB didn’t share the result of the question “Have you ever used an open source database in your job or company?”. In the context of this survey, that’s a pretty significant result to leave out.

One of the things that sets MySQL apart (in, IMHO, a very bad way) from other Open Source database projects/products such as PostgreSQL (license) and Firebird (license) is that the MySQL documentation is NOT Open Source. The MySQL documentation is and always has been copyright MySQL AB, and “… use of this documentation, in whole or in part, in another publication, requires the prior written consent from an authorized representative of MySQL AB”. This presents a major impediment to forking the server: who wants to re-write many hundreds of pages of documentation on things that haven’t even changed? Even if you’re OK with all of your new code being GPL (and anyone forking ought to be), and never being able to dual license or re-license your MySQL fork (oh well), you will have to start with no documentation, or publish an errata against the official MySQL documentation (which will only go so far).

Does this mean that MySQL is not really Open Source? I would say not exactly, although I could probably be convinced either way. Others may say yes. But it does go a long way to making the point that some things may not be quite as “open” as they initially appear. What do you think? Can a piece of software really be Open Source while its primary/only documentation is not? Did you know that the MySQL documentation was not Open Source?

* So what are the differences between is and MySQL?

No modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, ACL. Fewer data types. Less engines, less code. Assume the primary engine is transactional.

Also from the FAQ is that, right now at least, there is no intention to make this run natively on windows and they make the point:

* "This is not a SQL compliant relational..."

Very true, and we do not aim to be that.

It is a fork of MySQL that takes it backward to pre-5.0 in features but hopefully greatly reduces the bugs and instabilities. I plan to look at it but I don't see much enterprise adoption. It was the enterprise users who wanted stored procedures, views and most of the other stuff that is being removed. I think it will be adopted mainly by read-only (or mostly) web sites that want to serve many pages. That's ok. There's a huge market for that. If I found a fit for a client, I would consider it.

They are very honest with the goals:

* What is the target?

Deliver a microkernel that we can use to build a database that meets the needs of a web/cloud infrastructure. To this end we are exploring http interfaces, sharding enhancements, etc... do not expect an Oracle, MySQL, Postgres, or DB2.

I was reading my usual stable of blogs this morning and ran across two blog entries that got me thinking. First is Ronald Bradford's blog, The new kid on the block - Drizzle. Ronald gives a great overview of what Drizzle is trying to achieve, the current state of MySQL and reasons why Drizzle is a good idea. This is well worth a read. I'm just this far from being convinced. ;-)

The second was On MySQL Forks and MySQL's non-open source documentation on Jeremy Cole's blog. To answer his question, I did not know that the MySQL documentation was not open source. That is a very interesting point and one that never even occurred to me. I wonder if Sun would consider opening it?

Anyway, both of those got me thinking about forking MySQL. If you look at the Postgres community (not comparing the databases, just the goals of the community) over the years, they have taken great pains to not fork the database. The contrib modules are there so that the database can add functionality without forking. The companies who have tried to make a go at monetizing Postgres have also taken great pains to not fork the database.

In fairness to Drizzle, it may have a sort of contrib module like functionality (bolding is mine):

* What is the goal?

A micro-kernel that we then extend to add what we need (all additions come through interfaces that can be compiled/loaded in as needed). The target for the project is web infrastructure backend and cloud components.

With Postgres, even companies like Yahoo and Skype who needed specific functionality have contributed that back to the community so that the code will eventually be reworked into the mainline (or as a contrib). There is a very anti-forking bias in the Postgres community and I think that has helped advance the database.

Ignoring any commercial interests, will the MySQL community become fragmented by forking? Because honestly, the community is the important part of any open source project. If Sun is putting its resources behind MySQL 5.1 and 6, and if they don't open the documentation, where will Drizzle go?

I'm just not convinced that Drizzle is a good thing or that it's needed. Then again, if they concentrate on making this a natively scalable database for the cloud, maybe it is time for a fork. Although, I'm not sure that goal is achievable starting with the MySQL codebase. What do you think?

LewisC

Technorati : competition, fork, fragmentation, mysql

First, I’m testing on a new system, one with 32 gig of memory.  Currently,  the innodb_buffer_pool_size set to 28 gig.   I’m using the same size tables as previously, both Sale and SaleTenant have 120 million rows and are about 27 and 28 gig respectively.  This means that the tables fit into memory, so the following tests do not have an IO component.  Not perfect, but it shouldn't make a difference in the conclusions for these tests.  

For the other two tables, there are 100 tenants, and 1 million customers. 

The ddl looks like this (yeah, key and constraint names don’t make sense).   First, the non-multi-tenant table. 

CREATE TABLE  `test`.`Sale` (

  `orderId` int(11) NOT NULL,

  `customerId` int(11) NOT NULL,

  `productId` int(11) NOT NULL,

  `productBigId` int(11) NOT NULL,

  `unit` int(11) NOT NULL,

  `purchaseAmount` decimal(16,2) NOT NULL,

  `purchaseCost` decimal(16,2) NOT NULL,

  `purchaseDate` datetime NOT NULL,

  PRIMARY KEY  (`purchaseDate`,`orderId`),

  UNIQUE KEY `idx_sale_order` (`orderId`),

  KEY `pf_sale_product` (`productId`),

  KEY `pf_sale_customer` (`customerId`),

  CONSTRAINT `pf_sale_customer` FOREIGN KEY (`customerId`) REFERENCES `Customer` (`customerId`),

  CONSTRAINT `pf_sale_product` FOREIGN KEY (`productId`) REFERENCES `Product` (`productId`)

) ENGINE=InnoDB

Then the table with a tenantId in the table. 

CREATE TABLE  `test`.`SaleTenant` (

  `orderId` int(11) NOT NULL,

  `tenantId` int(11) NOT NULL,

  `customerId` int(11) NOT NULL,

  `productId` int(11) NOT NULL,

  `productBigId` int(11) NOT NULL,

  `unit` int(11) NOT NULL,

  `purchaseAmount` decimal(16,2) NOT NULL,

  `purchaseCost` decimal(16,2) NOT NULL,

  `purchaseDate` datetime NOT NULL,

  PRIMARY KEY  (`tenantId`,`purchaseDate`,`orderId`),

  UNIQUE KEY `idx_saletenant_order` (`orderId`),

  KEY `pf_saletenant_product` (`productId`),

  KEY `pf_saletenant_customer` (`customerId`),

  CONSTRAINT `pf_saletenant_customer` FOREIGN KEY (`customerId`) REFERENCES `Customer` (`customerId`),

  CONSTRAINT `pf_saletenant_product` FOREIGN KEY (`productId`) REFERENCES `Product` (`productId`),

  CONSTRAINT `pf_saletenant_tentant` FOREIGN KEY (`tenantId`) REFERENCES `Tenant` (`tenantId`)

) ENGINE=InnoDB

Now, the tenant table. 

CREATE TABLE  `test`.`Tenant` (

  `tenantId` int(11) NOT NULL,

  `tenantName` varchar(32) NOT NULL,

  PRIMARY KEY  (`tenantId`)

) ENGINE=InnoDB DEFAULT

And a customer table with a tenantId column. 

CREATE TABLE  `test`.`Customer` (

  `customerId` int(11) NOT NULL default '0',

  `customerName` varchar(32) NOT NULL,

  `tenantId` int(11) NOT NULL default '0',

  PRIMARY KEY  (`customerId`),

  KEY `pf_customer_tenant` (`tenantId`),

  CONSTRAINT `pf_customer_tenant` FOREIGN KEY (`tenantId`) REFERENCES `Tenant` (`tenantId`)

) ENGINE=InnoDB

#1) Against a table that is clustered by the TenantId, this query takes 0.5 seconds to run.  As it selects about 1/100 of the Sale Tenant database, the performance isn’t bad.

select sum(unit) from SaleTenant  where TenantId = 77;

And the query plan shows that the custered index was used to scan on the relevant rows. 

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: SaleTenant

         type: ref

possible_keys: PRIMARY

          key: PRIMARY