MyISAM is going to be deprecated (Bill Karwin is a big hitter on stackexchange and previously worked for Percona!) - you should change MyISAM to InnoDB NOW. You can do that by following the instructions here or here
AIUI, even the system tables in MySQL have4/are been/being moved to InnoDB, see here and here. The latter reference appears to indicate that most system tables have moved to InnoDB in the upcoming 8 release.
You can read some of the pros/cons of MyISAM/InnoDB here.
Even if you're not using the capabilities of the InnoDB engine now, you may need to use them in the future.
To answer the question, you have two performance tuning options:
- you can set your InnoDB
READ ONLY from here,
or you can
- set the entire server to be
READ ONLY as per here.
You may want to test these, but it is my belief that any small performance penalty is worth paying for the advantages that the InnoDB engine brings!
It won't be updating, inserting or deleting any data.
This is good for performance - there's no need for the engine to maintain linked lists of pointers to new records and/or other transactions in this case. You should set your transactions to read only as indicated above.
There won't be any join we need to use, at a time tool will be
interacting with a single table exclusively.
Hmmm... a database without joins - always been a puzzling concept to me. You do realise that the optimiser can make better decisions about which tables to process in which order if there are explicit joins between the tables - those who argue that
FOREIGN KEYs incur a performance penalty don't understand
Tool will use only "order by", "where", "limit (for paging)" clause
on the the database.
GROUP BY surely? Otherwise, why not simply use a spreadsheet? In any case, presenting a human user with thousands/millions of lines of data (or in this case apparently, records) is pretty pointless - humans will just scan and skip through pages of numbers.
All the table will be having a column "rowno" as a primary key. There is no FK relationship between the tables.
See above about
FOREGIN KEYs. No problem with having a simple integer
PRIMARY KEY as your surrogate