The best way to do this, probably not to do this, is that people insist on storing their data in a way that requires SQL "gymnastics" to extract meaningful information when there are much simpler ways to achieve the desired result if you just structure your schema a bit better :-)
The correct way to do this, in my opinion, is to have the following table:
ID Col Val -- --- --- 1 1 3 1 2 34 1 3 76 2 1 32 2 2 976 2 3 24 3 1 7 3 2 235 3 3 3 4 1 245 4 2 1 4 3 792
with ID/Col as the primary key (and, possibly, Col as an additional key, depending on your needs). Then your query becomes simple select min(val) from tbl and you can still process the individual "old columns" separately, using, where col = 2 in your other queries. It also makes it easy to expand as the number of "old columns" increases.
This makes your queries a lot easier. The general rule that I usually use is that if you ever have something that looks like an array in a database row, you are probably doing something wrong and should consider restructuring the data.
However, if for some reason you cannot change these columns, I would suggest using insert and update triggers and add another column for which these triggers are set to at least Col1/2/3 . This will shift the "cost" of the operation from the choice to update / insert, to which it refers - most of the database tables in my experience are read much more often than they are written, so the cost of writing, as a rule, becomes more effective over time.
In other words, the minimum for a row changes only when one of the other columns changes, so that’s why you should calculate it, and not every time you choose (what is lost if the data does not change). Then you will get a table, for example:
ID Col1 Col2 Col3 MinVal -- ---- ---- ---- ------ 1 3 34 76 3 2 32 976 24 24 3 7 235 3 3 4 245 1 792 1
Any other option that must make decisions during select usually a bad idea in terms of performance, since the data changes only when inserting / updating - adding another column takes up more space in the database and will be slightly slower for inserts and updates, but can be much faster for selection - the preferred approach should depend on your priorities, but, as already mentioned, most tables are read much more often than they are written.