Forgive my bluntness, but IMO it is silly to attempt to retrieve a 100,000
rows, except for reporting purposes, and in that case, said reports ought to
run against a replica, not the OLTP instance.
Far better, IMO, is to present (in the UI) an alphabet as buttons, plus a
textbox for refinements. The alphabet buttons cause the recordSource to
change to something like "SELECT * FROM Clients WHERE ClientName LIKE 'A*'.
Click the B button and the RecordSource changes to "SELECT * FROM Clients
WHERE ClientName LIKE 'B*'. IMO, such an interface gives the user all the
power she needs, and costs the system as little as possible.
To accomplish this, all you need is a sproc that accepts one parameter, that
being the letter corresponding to the letter-button the user pressed.
I have implemented exactly this solution on a table with only half the
number of rows you cite, but it works beautifully and it is quick as
On Wed, Sep 14, 2011 at 9:24 AM, Ananda Kumar <anandkl@stripped> wrote:
> Dr. Doctor,
> What kind of 100000 entries? Is it insert,update delete etc.
> On Wed, Sep 14, 2011 at 6:30 PM, The Doctor <doctor@stripped
> > Question:
> > How can you optimise MySQL for 100000 entires?
> > Just running OSCemmerce and it is slow to pull up a who catalogue.
> > --
> > Member - Liberal International This is doctor@stripped Ici
> > doctor@stripped
> > God, Queen and country! Never Satan President Republic! Beware AntiChrist
> > rising!
> > https://www.fullyfollow.me/rootnl2k
> > Ontario, Nfld, and Manitoba boot the extremists out and vote Liberal!
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe: http://lists.mysql.com/mysql?unsub=1