I honestly don’t know. Highly specialized third party software such as MySQL usually is also highly optimized and from my experience it’s always worth considering using it regardless of the amount of data. For an accurate response, I’d either need more knowledge about the internal workings of the software in question or a handful of benchmark tests.
Don’t quote me on the following, but in this particular case I don’t think you’ll gain any significant performance gain for either approach, depending on your method of implementation. Data is most likely to be immutable during the actual gameplay, as such it’s likely you’ll read in all the cards at the startup of the game and never do anything with the database again for the session. If you were to mutate the cards at runtime often it would be much more efficient to use MySQL since it’s IO routines are more optimized and the database file on drive is not rewritten every time a card changes. As a rule of thumb, you’ll want to avoid as many IO operations as possible as the drive is considerably slower than RAM.
MySQL excels at working with masses of data over a longer period of time from multiple clients, i.e. hundreds of thousands of cards accessed by dozens or hundreds or even thousands of clients, which you’re unlikely to be using. If I were to give an educated guess, for a standard card game made of a couple hundred cards only, the spreadsheet approach would suffice.
Also consider that MySQL requires a third party software to be running on the client or server. MySQLite would add an overhead to opening and maintaining the database, so in actuality it might be (very slightly) more efficient to use spreadsheets for this specific case.
Again, a couple of benchmark tests would either confirm or deny this.