Tell somebody relevant that currently, your team is moving towards a dangerous situation - creating what in my last job, we called a "lone peak of skill". Ideally, somebody relevant will be an agile coach, because agile coaches are trained to recognize the danger in this, and it is their job to prevent it. If you don't have an agile coach, the next choices would be, in that order: scrum master, team lead, or the manager to whom you report. That supposes that your company is more or less following the traditional definition of these roles - you may have to change your choice depending on who you think will grasp the situation, and will react with understanding on the human level too.
The reason why this is a better approach is that it makes them aware that the team has a problem, and through that, the company. As you will be talking to somebody responsible for the team, it makes it a problem they are responsible for. This is directly opposed to the way you have presented it until now - that it is you who has a problem related to personal preferences. There is a tacit understanding that it is management's responsibility to recognize and define the tasks which need to be done for the business to move ahead, and it is the specialists' responsibility to get these tasks done. The current top answers reflect how most people (especially most managers) see this cultural norm. Being choosy is allowed to some extent, but can quickly win you a reputation of being unprofessional. If a manager promises you to try to get you more enjoyable tasks, this is seen as a courtesy, and has lower priority than the current business goals.
If you, or your somebody relevant is not recognizing the problem for the company: a skill being concentrated in a single person is very efficient in the short-term and very damaging in the long term. There is not only the famous bus factor, but also more subtle effects like you not being flexibly available for that new project they wanted you for, because you are stuck maintaining all the company's SQL, and the juniors never gaining any experience, because they stay firmly in their comfort zone.
That state is not only problematic for the company/team, it is also a state that is a natural attractor for teams. It starts out innocently, with somebody getting slightly more knowledge about something than the other team members (if it is not a language, then it is a subsystem, usually one that person wrote first), and then all tasks about it being left to that team member, because they know more about it than the others. In the worst case, it is not just the others being unwilling to jump the hurdle of "I don't know how to do this yet", it is the experienced person not having the didactic fortitude to let them blunder their way to expertise, instead taking it out of their hands and saying "let me show you how it is done". And because it happens on its own, it is somebody's - ideally an agile coach's - job to actively steer the team to a different state, in which expertise is shared, and nobody has (or is allowed to use) the excuse of "but Hunkabonk is so much better at it than me".
In a perfect company, somebody relevant will listen to you, recognize the problem, and take measures to counteract it. It will not result in you never doing any SQL, but rather, in both the SQL tasks and the C# tasks being equally distributed among the team, which will hopefully make you happy (it may turn out that what bothers you is not the hours you are doing SQL - which will be reduced - but the unfairness of you being the only one who has to, or the feeling that you complained and were not heard). In just about any real-life company, you may encounter anything on the spectrum from the perfect company's reaction, to a blank "I don't understand, it's great that you are growing to be an SQL experts, so there is no problem." From there, it depends on your particular circumstances to recognize whether there is hope for the situation to change, or if you have to fall back on Pete B.'s answer.