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 lightning. HTH, Arthur On Wed, Sep 14, 2011 at 9:24 AM, Ananda Kumar <anan...@gmail.com> wrote: > Dr. Doctor, > What kind of 100000 entries? Is it insert,update delete etc. > > regards > anandkl > > On Wed, Sep 14, 2011 at 6:30 PM, The Doctor <doc...@doctor.nl2k.ab.ca > >wrote: > > > 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 doc...@nl2k.ab.ca Ici > > doc...@nl2k.ab.ca > > 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=anan...@gmail.com > > > > >