Optimal SD Access Strategy?

If those values are constant, or if you don't mind reprogramming the whole thing just to do a little change, then why not storing them in its flash memory? Although due to compiler limitations, arrays of any kind cannot exceed 32 KB (32767 bytes) in size, so in that case splitting up the lookup table is the only option.

Nevertheless, continuing to your original question:

If your concern is about optimal performance on an SD card data access (read), then consider this when deciding a size for your cache:

  • The library already caches 512 bytes of data, so any read attempt within this boundary will be almost instantaneous (1 microsecond at most). Outside of this boundary (every 512th byte) will trigger a cache reload, that should take 1-4 microseconds depending on the SPI's clock frequency.
  • There's also another key factor inside the filesystem itself: something called cluster (aka allocation unit) size; you can know that by either running the CardInfo example, or by creating a non-empty and no larger than 512 bytes big file, and then checking its "size in disk" property in the file explorer of your PC. Like with the previously mentioned cache, every cluster-size bytes will trigger another kind of reload; but this time it's the slowest one because of how FAT systems work. This special process might take 10-40 microseconds in the worst case; probably not a big deal anyway, but on time-critical events who knows...

In summary: reading a byte from an SD card most of the time it's nearly instantaneous, eventually it will take a bit longer (once a little while), and sometimes even longer (not so often though).
The first situation occurs when the data is already in RAM by the library. The second one when accessing data outside the library's cache (just loads the next data block). The third one when accessing data outside the current filesystem-defined "cluster" (queries the FAT for the next file's cluster and then loads the corresponding data block).

Too technical I know, but bear with me this is more exactly what you're dealing with when deciding the size.