Re: slower queries after partitioning

[Rick James]

select  a.TickerID, b.Ticker, b.Name
    from  quotes_copy as a,
          tickers as b
    where  DBDate =
      ( SELECT  min(DBDate) from  quotes)
      and  a.TickerID = b.TickerID;

-->

select  a.TickerID, b.Ticker, b.Name
    from  quotes_copy as a,
          tickers as b
    where  a.TickerID = b.TickerID
    ORDER BY a.DBDate
    LIMIT 1; 
and have this
KEY `TickerID` (`TickerID`, DBDate)
instead of
KEY `TickerID` (`TickerID`)

Any query on DBDate has to hit all partitions.

"Why is the partitioned table so much slower?" The lure of PARTITION beguiling, but often deceptive. Only 3M rows, and no query that takes advantage of PARTITIONing --> no benefit. I'm surprised to see it running that much slower.

double(12,4) -- not optimal for money -- this rounds to 4 decimal places, then converts to binary, which introduces a small error. Consider DECIMAL(10,4).

A 3:5 split will make a mess of your fractions.

Volume for some indexes has exceeded 4G.

With only 704 tickers, `TickerID` int(11) unsigned is excessive. Consider SMALLINT UNSIGNED (max of 65,535).

`DBDate` int(11) unsigned -- You don't what to use the builtin DATE datatype?

This one is fast because it simply fetches the first row in the table:
select min(DBDate) from quotes; 31 ms
With PARTITIONing, it has to fetch 250 'first' rows, sort them, then deliver the first. (Or something like that)