Sphinx matching index of found value of one MVA field to another?

Question

Sphinx

Attention! The task is quite abnormal and I know that this is not the intended purpose of the Sphinx.
Simplified table structure: id int, default_price int, prices mva, regions mva.
In addition to these fields, there are a dozen more text fields.
Entry example:
id = 5464356; / item
number default_price = 2250; / price of goods in most regions
prices = 2500, 1800, 2500, 3250, 1800; / price variation in regions (promotions, sales, liquidations)
regions = 1, 2, 24, 58, 66 / id of regions with a non-standard price
It reads like this: in region No. 1, the price of goods is 2500, in 2 = 1800, in 24 = 2500 , in 58 = 3250 and in 66 = 1800.
In all other regions the price is 2250.
Purpose: sort the list of products by price, taking into account the price of a particular region.
In each region, the price can vary greatly.
What is now: SELECT * FROM barahlo ORDER BY default_price;
What is missing now: get a single value from prices mva whose index matches the index found in the regions field
As I see it in pseudo-SQL solution:
SELECT *, IF(regions IN (58), VALUEFROMMVA(prices, regions IN (58)) , default_price) sort_price FROM barahlo
ORDER BY sort_price;
Alternative solution: since there are more than 100 regions, and there are tens of thousands of products, the price index in a separate field for each region + 10 text fields will look too terrifying.
But it seems that this is the only boneless option.

Answer 1

The issue was resolved without crutches and creating a huge index =)
As a "primary key" I took a bunch of id + price, and in regions a list of regions with this price.

Answer 2

Yes, here "on the forehead" the task is not solvable at all.
MVA does NOT have any indexes. This is an analogue of the Set structure, not a Vector. Inside, for convenience, it is stored in ascending sorted form. Accordingly, exactly at the moment when you put prices there - the duplicates will be removed, the prices themselves will be sorted out - and the entire proposed scheme will "fall apart".
So your option with including the price in the "primary key" is quite good.
Also (as a variation of the same) you can put the price in a separate ft-field (then in the search you get something like '@title iPhone 5S @price 2500'. Or (another option) not in the field but in a special token (" price2500").